При включении Windows для установки системного времени через Интернет появляется следующее диалоговое окно:
Имеет ли значение, какой сервер времени я выберу?
Как я узнаю, что один из них «лучше» других?
решение1
Имеет ли значение, какой сервер времени я выберу?
Короткий ответ: Да.
Хотя все серверы NTP стремятся поддерживать синхронизацию с UTC, их расстояние от вас и промежуточные сети влияют на такие факторы NTP, как задержка и джиттер. Существует также вопрос доступности, не все серверы доступны постоянно и навсегда.
Насколько мне известно, UTC и служба NTP уровня 0 не контролируются, не регулируются и не предоставляются USNO даже в пределах США. UTC было определено МСЭ и основано на TAI плюс дополнительные секунды (я полагаю, определенные ERS). TAI поддерживается международной группой из 70 лабораторий (одной из которых является USNO, но также включающей NRL в Вашингтоне и NIST в Боулдере) и координируется BIPM во Франции.
Я бы использовалпул ntpдля вашего региона.
Как я узнаю, что один из них «лучше» других?
Запустив настоящий NTP-клиент на подходящей системе и посмотрев статистику
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
connorw600.info europium.canoni 16 u 182d 1024 0 0.000 0.000 4000.00
*dns0.rmplc.co.u ntp1.ja.net 2 u 659 1024 377 27.015 -4.936 1.034
+82.113.154.206 ntp4.ja.net 2 u 700 1024 377 24.853 -4.827 0.788
+dawn.rt.uk.eu.o ntp1.nl.uu.net 2 u 913 1024 377 29.364 -5.614 0.691
Похоже, connorw600.info… будет плохим выбором.
решение2
Согласно Википедии,Протокол сетевого времениработает следующим образом:
Чтобы синхронизировать свои часы с удаленным сервером, клиент NTP должен вычислить время задержки приема-передачи и смещение. Задержка приема-передачи вычисляется как , где — время передачи пакета запроса, — время приема пакета запроса, — время передачи пакета ответа, — время приема пакета ответа. — время, прошедшее на стороне клиента между отправкой пакета запроса и получением пакета ответа, а — время, которое сервер ждал перед отправкой ответа. Смещение задается как .
Синхронизация NTP корректна, когда входящие и исходящие маршруты между клиентом и сервером имеют симметричную номинальную задержку.. Если маршруты не имеют общей номинальной задержки, синхронизация имеет систематическое смещение в половину разницы между временем движения вперед и назад.
Из этого объяснения мы можем признать, что для точной синхронизации часов у вас должна быть низкая разница во времени задержки, с которой сервер отвечает на ваш запрос, и времени задержки, с которой вы отвечаете серверу, завершающему синхронизацию. Таким образом, если сервер, который вы запускаете, находится далеко от вас (я имею в виду, что между вами и сервером NTP находится много "точек" или маршрутизаторов), вероятность того, что у пакетов NTP, которые вы получаете и отправляете, будет разный "путь", увеличивается.
Итак, исходя из моей интерпретации этого случая, лучшим сервером для синхронизации ваших часов является тот, который "ближе". Я имею в виду, что если вы получите трассировку "точек" между вами и сервером, вы выберете тот, у которого меньше скачков. Вы можете использовать команду "tracert" из Windows, чтобы определить лучший для вас публичный NTP-сервер.
Также помните, что помимо этих стандартных опций, существуютмножество публичных NTP-серверовв Интернете.
решение3
Короткий ответ: Нет.
Неважно. Они все одинаковы. Более или менее, они являются резервными копиями друг друга. В Соединенных Штатах Департамент службы времени Обсерватории ВМС США является официальным хранителем времени. Все остальные, включая корпорации и, в особенности, любые правительственные организации США, отражают его время. Поэтому все доступные в раскрывающемся списке варианты — это одно и то же время. Следовательно, нет одного, который был бы «лучше» других.
решение4
На самом деле существует большая разница в задержке. Использование пула, например, может привести к переменной задержке. Пул пытается подключить вас к серверу рядом с вами. По моему опыту, время «поиска» варьируется от запроса к запросу. В одном из моих приложений я был вынужден сделать пул резервным копированием 3-го уровня, потому что у Google и Microsoft задержка была более постоянной.