Дрейф часов на Windows - PullRequest
       37

Дрейф часов на Windows

15 голосов
/ 19 сентября 2008

Я разработал службу Windows, которая отслеживает деловые события. Он использует часы Windows для отметки времени событий. Тем не менее, лежащие в основе часы могут довольно сильно дрейфовать (например, терять несколько секунд в минуту), особенно когда процессоры усердно работают. Наши серверы используют службу времени Windows, чтобы поддерживать синхронизацию с контроллерами домена, которая использует NTP под капотом, но частота синхронизации контролируется политикой домена, и в любом случае даже синхронизация каждую минуту все равно допускает существенный сдвиг. Существуют ли какие-либо методы, которые мы можем использовать для поддержания стабильности часов, кроме использования аппаратных часов?

Ответы [ 13 ]

17 голосов
/ 19 сентября 2008

Тики должны быть предсказуемы, но на большинстве аппаратных средств ПК - , потому что они не предназначены для систем реального времени - другие прерывания устройства ввода-вывода имеют приоритет над прерыванием такта, а некоторые драйверы выполнять расширенную обработку в процедуре обработки прерывания, а не откладывать ее на отложенный вызов процедуры (DPC), что означает, что система может быть не в состоянии обработать прерывание тактового сигнала до (иногда) долгое время после того, как оно было сигнализировано .

К другим факторам относятся контроллеры ввода / вывода с мастерингом шины, которые крадут много тактов шины памяти у ЦП, что приводит к тому, что ему не хватает пропускной способности шины памяти в течение значительных периодов.

Как уже говорили другие, аппаратные средства генерации тактового генератора также могут изменять свою частоту при изменении значений компонентов в зависимости от температуры.

Windows позволяет регулировать количество тиков, добавляемых к часам реального времени при каждом прерывании: см. SetSystemTimeAdjustment. Однако это сработает, только если у вас будет предсказуемый перекос часов. Если часы только немного выключены, клиент SNTP (служба «Время Windows») отрегулирует эту асимметрию, чтобы тактовая метка немного ускорялась или замедлялась, чтобы двигаться к правильному времени.

12 голосов
/ 09 марта 2009

Не знаю, применимо ли это, но ...

Проблема с Windows заключается в том, что если вы измените разрешение таймера с помощью timeBeginPeriod () , часы будут дрейфовать.

На самом деле, существует ошибка в реализации Java-функции Thread wait()os::sleep()) для Windows, которая вызывает такое поведение. Он всегда устанавливает разрешение таймера равным 1 мс перед ожиданием, чтобы быть точным (независимо от продолжительности ожидания), и восстанавливает его сразу после завершения, если другие потоки еще не спят. Этот набор / сброс затем запутает часы Windows, которые ожидают, что квант времени Windows будет довольно постоянным.

Sun фактически знает об этом с 2006 года и не исправил это, УЖАС!

Из-за этого у нас на самом деле часы шли в два раза быстрее! Простая Java-программа, которая спит 1 миллисекунд в цикле, демонстрирует это поведение.

Решение состоит в том, чтобы установить временное разрешение самостоятельно на что-то низкое и сохранять его там как можно дольше. Используйте timeBeginPeriod () для управления этим. (Мы установили его на 1 мс без каких-либо побочных эффектов.)

Для тех, кто занимается кодированием на Java, проще всего это исправить, создав поток, который спит до тех пор, пока приложение живет.

Обратите внимание, что это решит эту проблему на машине в целом, независимо от того, какое приложение является фактическим виновником.

5 голосов
/ 19 сентября 2008

Вы можете запустить "w32tm / resync" в файле .bat запланированной задачи. Это работает на Windows Server 2003.

4 голосов
/ 19 сентября 2008

Кроме частой повторной синхронизации часов, я не думаю, что вы можете многое сделать, кроме как приобрести новую материнскую плату, поскольку ваш тактовый сигнал, кажется, не на правильной частоте.

2 голосов
/ 13 февраля 2012

http://www.codinghorror.com/blog/2007/01/keeping-time-on-the-pc.html

Часы ПК обычно должны быть с точностью до нескольких секунд в день. Если вы испытываете значительный сдвиг часов - порядка минут в день - первое, что нужно проверить, это ваш источник переменного тока. Я лично наблюдал системы с ИБП, подключенным к другому ИБП (это, кстати, нет-нет), который набирал минуты в день. Удаление ненужного ИБП из цепи устранило проблему времени. Я не инженер по аппаратному обеспечению, но я предполагаю, что некоторый сигнал синхронизации в питании используется микросхемой часов реального времени на материнской плате.

2 голосов
/ 13 февраля 2012

Как уже упоминалось, Java-программы могут вызывать эту проблему.

Другим решением, которое не требует модификации кода, является добавление аргумента VM -XX:+ForceTimeHighResolution (находится на странице поддержки NTP ).

9.2.3. Windows и Sun виртуальная машина Java

Виртуальную машину Sun Sun необходимо запустить с параметром> -XX: + ForceTimeHighResolution, чтобы избежать потери прерываний.

См. http://www.macromedia.com/support/coldfusion/ts/documents/createuuid_clock_speed.htm для получения дополнительной информации.

Из указанной ссылки (через Wayback machine - исходная ссылка исчезла):

ColdFusion MX: CreateUUID увеличивает системную тактовую частоту Windows

Вызов функции createUUID несколько раз под нагрузкой в Macromedia ColdFusion MX и выше может вызывать системные часы Windows чтобы ускорить. Это проблема с виртуальной машиной Java (JVM) в который Thread.sleep вызывает менее 10 миллисекунд (мс), вызывает Системные часы Windows работают быстрее. Такое поведение было изначально подано как Sun Java Bug 4500388 (developer.java.sun.com/developer/bugParade/bugs/4500388.html) и имеет подтверждено для JVM 1.3.x и 1.4.x.

В ColdFusion MX функция createUUID имеет внутренний поток. вызов 1 миллисекунды. Когда createUUID интенсивно используется, Системные часы Windows получат несколько секунд в минуту. Скорость ускорение пропорционально количеству вызовов createUUID и тому загрузить на сервер ColdFusion MX. Macromedia наблюдала это поведение в ColdFusion MX и выше в Windows XP, 2000 и 2003 системы.

1 голос
/ 04 сентября 2009

Так как у вас большой бизнес:

Возьмите старый ноутбук или что-то, что не очень хорошо для многих, но, кажется, имеет более или менее надежные часы, и назовите его Timekeeper. Единственная задача Хронометриста состоит в том, чтобы раз в каждые (скажем) 2 минуты отправлять на сервер сообщения с указанием времени. Вместо того чтобы использовать часы Windows для своих временных меток, серверы будут записывать время с последнего сигнала хронометриста плюс время, прошедшее с момента получения сигнала. Проверяйте часы хронометриста у своих наручных часов один или два раза в неделю. Этого должно быть достаточно.

1 голос
/ 19 сентября 2008

Смещение часов может быть следствием температуры; возможно, вы могли бы попытаться получить более постоянную температуру - возможно, используя лучшее охлаждение? Вы никогда не потеряете дрейфа полностью.

Использование внешних часов (приемник GPS и т. Д.) И статистический метод для привязки времени ЦП к абсолютному времени - вот что мы используем здесь для синхронизации событий в распределенных системах.

1 голос
/ 19 сентября 2008

Синхронизация чаще. Посмотрите на записи реестра для службы W32Time , особенно «Период». «SpecialSkew» звучит так, как будто это поможет вам.

1 голос
/ 19 сентября 2008

Увеличьте частоту повторной синхронизации. Если синхронизация выполняется с вашим главным сервером в вашей сети, нет причин не выполнять синхронизацию каждую минуту.

...