gadgets - Дрифт часов в Windows

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

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

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

Использование внешних часов (GPS-приемник и т. Д.), А также статистический метод связывания времени процессора с Absolute Time - это то, что мы используем здесь для синхронизации событий в распределенных системах.

На каких серверах вы работаете? В десктопах, когда я сталкивался с этим, с включенным FSB с расширенным спектром, возникают некоторые проблемы с синхронизацией прерываний, что и делает тактику часов. Может захотеть узнать, является ли это вариантом в BIOS на одном из этих серверов и отключить его, если он включен.

Другой вариант, который у вас есть, - отредактировать интервал опроса времени и сделать его намного короче, используя следующий раздел реестра, скорее всего, вам придется его добавить (обратите внимание, что это значение DWORD, а значение - в секундах, например 600 на 10 минут) :

Вот полная работа над этим: KB816042

Однажды я написал класс Delphi для обработки временных пересинхронов. Он вставлен ниже. Теперь, когда я вижу команду «w32tm», упомянутую Ларри Сильверманом, я подозреваю, что потратил свое время.

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

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

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

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

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

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

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

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

Поскольку кажется, что у вас большой бизнес:

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

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

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

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

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

Солнце на самом деле известно об этом с 2006 года , и не исправил его, AFAICT!

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

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

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

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

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

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