Имеет ли значение, какой NTP сервер времени я выбираю в Windows?

Когда я настраиваю Windows для установки системного времени через Интернет, мне показывается следующий диалог:

Имеет ли значение, какой сервер времени я выберу?

Как мне узнать, если один “лучше” остальных?

Имеет ли значение, какой сервер времени я выберу?

Краткий ответ: Да

Хотя все NTP-серверы стремятся поддерживать синхронизацию с UTC, их расстояние от вас и промежуточные сети влияют на такие факторы NTP, как задержка и джиттер. Также есть вопрос доступности, не все серверы доступны постоянно.

Насколько мне известно, UTC и служба NTP stratum-0 не контролируются, не регулируются и не предоставляются USNO, даже в США. UTC был определен ITU и основан на 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… будет плохим выбором.

Согласно Википедии, протокол сетевого времени работает следующим образом:

Для синхронизации своих часов с удалённым сервером NTP-клиент должен
вычислить время задержки туда-обратно и смещение. Время задержки
вычисляется как , где — это время
передачи пакета запроса, — время
получения пакета запроса, — время передачи пакета ответа, а — время приёма пакета ответа. — это время, прошедшее на стороне клиента между отправкой пакета запроса и приёмом пакета ответа, в то время как
— это время, которое сервер ожидал перед отправкой ответа. Смещение дается как .

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

Из этого объяснения мы можем признать, что для точной синхронизации часов вы должны иметь низкую разницу во времени задержки, с которой сервер отвечает на ваш запрос, и во времени задержки, с которой вы отвечаете серверу, завершая синхронизацию. Таким образом, если сервер, который вы используете, находится далеко от вас (я имею в виду, что между вами и NTP-сервером много “точек” или маршрутизаторов), вероятность появления другого “пути” для NTP-пакетов, которые вы получаете и отправляете, возрастает.

Таким образом, по моему интерпретации, лучший сервер для синхронизации ваших часов — это “ближайший”. Я имею в виду, что если вы получите трассировку “точек” между вами и сервером, вы выберете тот, у которого наименьшее количество переходов. Вы можете использовать команду “tracert” в Windows, чтобы определить лучший публичный NTP-сервер для вас.

Также помните, что помимо этих стандартных вариантов, в Интернете есть много публичных NTP-серверов.

Краткий ответ: Нет.

Это не имеет значения. Они все одинаковы. Более или менее, они резервируют друг друга. В пределах Соединенных Штатов Департамент временной службы ВМФ США является официальным хранителем времени. Все остальные зеркалируют его время, включая корпорации и, в особенности, любые правительственные структуры США. Поэтому все доступные варианты из списка предоставляют одно и то же время. Таким образом, нет такого, который был бы “лучше” остальных.

На самом деле существует большая разница в задержке. Использование пула, например, может вводить переменную задержку. Пул пытается подключить вас к серверу, находящемуся рядом с вами. Время “поиска” по моему опыту варьируется от запроса к запросу. В одном из моих приложений я был вынужден сделать пул сервером третьего уровня резервного копирования, потому что у Google и Microsoft была более стабильная задержка.

Это действительно не имеет значения, но я бы предложил использовать службу ntp, предлагаемую в вашей стране, чтобы снизить джиттер/задержки, как указал @Diogo.

В США это будет nist.gov, в Швейцарии ntp.metas.ch (псевдоним для ntp11.metas.ch через ntp13.metas.ch), в Германии ptbtime1.ptb.de через ptbtime4.ptb.de.

Если вы не доверяете своему правительству в плане времени, вы можете использовать публичную службу от pool.ntp.org с префиксом кода страны, если хотите. Каждый может внести свой вклад в пул (я это делаю) и, вероятно, вы получите более низкий уровень стратификации от правительственного сервера, но ближе к вам.

Моя практика заключается в настройке маршрутизатора как ntp-сервера а) чтобы ваши локальные устройства имели одно и то же время и б) чтобы вам не приходилось обновлять время с wan-сервера так часто. Маршрутизатор будет устанавливать синхронизацию времени.

К сожалению, клиент Windows DHCP игнорирует опцию DHCP (4) для предложения конкретного ntp-сервера. Что возможно, это чтобы ваши Windows-клиенты использовали стандартный сервер (time.windows.com) и у вас была указана NS-правило для перенаправления на ваш локальный NTP-сервер. Я так делаю для моих кухонных приборов, которые получают время от довольно экзотических, жестко закодированных имен NTF-серверов.