Вопрос или проблема
У меня есть сервер NTP на Windows 10, который использует в качестве ссылки свой ЛОКАЛЬНЫЕ ЧАСЫ. У него есть клиенты NTP на Windows 10 и Linux.
Узлы Windows используют службу времени Windows (клиент и сервер), клиенты Linux используют chrony.
Вопросы:
-
Правильна ли методология измерения точности на узлах Windows?
Статья о Windows рекомендует в качестве метода расчета высокой точности вычислять однонаправленную задержку (корневая дистанция) вместе с другими критериями, указанными по ссылке.
Ниже приведен метод, который я использую. Он показывает точность до 0,5 миллисекунд. Я слышал, что NTP не может быть настолько точным, и сомневаюсь в методологии:
(Среднее (вычисление RTT от Win10NTPClient до NTPServer)/2)
-
Верна ли методология для узлов Linux NTP, использующих chrony? Я пытаюсь понять методологию в Как точны мои системные часы
Последний столбец файла
/var/log/chrony/tracking.logпоказывает максимальную ошибку. Как я могу интерпретировать это как точность? Верно ли это предположение? -
Почему chrony и Windows используют разные методологии, даже если они используют протокол NTP?
Пожалуйста, помогите мне понять эти концепции. Я слышу о разных методах, и некоторые из них просто ссылаются на использование NTPOffset, и это значение очень маленькое (в наносекундах), и я сомневаюсь в этом.
(Этот ответ предполагает, что вы игнорируете замечание @HBruijn о вашем исходном источнике времени, чего вы действительно не должны делать. NTP-сеть хороша ровно настолько, насколько хороши ее корневые серверы.)
На типичной локальной сети Gigabit Ethernet без специальной настройки я бы ожидал, что смещения NTP в диапазоне 0.5 мс будут “нормальными”. Смещения в наносекундном диапазоне кажутся довольно оптимистичными, если только вы не используете очень быстрые узлы и сети.
На моей сети 1 Гбит/с (с моделями процессоров, которым от 7 до 12 лет) я получаю смещения в основном в диапазоне ± 200 мкс. Вот график трех узлов за последнюю неделю:
Каждый из узлов на графике выше находится в той же сети, что и их источник stratum 1 (Raspberry Pi 4 модель B с GPS-приемником) и работает с chrony 4.2 на Linux. Они выполняют другие задачи, но даже если бы они были полностью свободны от задач, вряд ли они смогли бы достичь смещений на уровне наносекунд.
Ответ или решение
Вопрос о точности времени в операционных системах Windows и Linux, использующих протокол NTP (Network Time Protocol), представляет интерес не только с точки зрения теории, но и по практическим причинам, связанным с консистентностью временных меток в распределённых системах. Разберёмся детально в измерении точности синхронизации времени и различиях между Windows и Linux.
Теория
-
Протокол NTP: NTP – это сетевой протокол для синхронизации часов в компьютерной сети. Он позволяет уменьшить отклонения системного времени, используя многоуровневую архитектуру, гдеroot-источниками служат атомные часы или GPS-ресиверы.
-
Точность синхронизации: Ключевой элемент NTP – достижение высокой точности времени. Точность измеряется в миллисекундах или микросекундах. Важно понимать, что на точность влияет множество факторов: качество сетевого соединения, рабочая нагрузка на серверы, аппаратные особенности серверов и клиентов.
-
Методы измерения:
- Для Windows используется служба Windows Time (W32Time), которая оперирует понятиями "Root Distance" и измеряет временные отклонения через "RTT" (Round Trip Time).
- В Linux, с использованием chrony, точность оценивается через log-файлы и через анализ таких параметров, как "maximum error", что указывает на наивысшую возможную ошибку в синхронизации времени.
Пример
Windows:
- В примере с Windows, вы подразумеваете использование "RTT/2" как метода оценки точности. В документации Microsoft говорится, что "Root Distance" учитывает "one-way latency" и погрешности связи. Для времени передачи сигнала (RTT) в 1 миллисекунду средняя ошибка составит 0,5 миллисекунды, но это не учитывает других системных задержек и может быть излишне оптимистично.
Linux с chrony:
- Chrony использует журнал \var\log\chrony\tracking.log, где последняя колонка указывает на максимальную возможную ошибку. Например, значение в 200 микросекунд указывает, что максимальная величина ошибки калибровки времени составляет 0,2 миллисекунды. Это приближенные значения и тоже требуют учёта задержек и состояния сети.
Применение
Почему различаются методики?
Отличия связаны как с архитектурой каждой операционной системы, так и с уровнем поддержки протокола NTP и его реализации. Windows и Linux имеют различную реализацию сетевого стека, что объясняет различия в подходах:
- Windows NT Protocol подстроен под специфические требования корпоративных Windows-сетей.
- Chrony адаптирован для повышения точности в условиях изменяющихся сетевых топологий и может компенсировать большие вариации задержек лучше, чем простое использование Windows Time.
Для точности критично понимать, что со временем даже самые небольшие задержки могут накопиться и вызвать значительные отклонения. Поэтому для приложений, критичных к времени, таких как финансовые системы или системы измерений, выбор правильной архитектуры NTP сервера играет ключевую роль.
Если у вас нет точного источника времени, получить высокую точность в миллисекундах ответственность практически нереально. Даже на хорошем оборудовании и в идеальных условиях реальная точность обычно ограничена внешними факторами, такими как пропускная способность сети, загруженность процессора и прочее.
Таким образом, для достижения максимальной точности всегда рекомендуется использовать специализированные решения на аппаратной основе, такие как GPS-ресиверы или атомные часы, а также обеспечивать минимальные сетевые задержки и оптимальную производительность оборудования.