Обычно, когда машина полностью теряет соединение, ntpd пропускает пару опросов и помечает все источники как неисправные. Что кажется вполне логичным. Но я встречал ситуацию, когда сервер остается отмеченным как текущий источник времени, а его охват равен 0.
Сервер развернут в той же подсети, что и целевая машина, обеспечивая очень малую задержку, смещение и джиттер. Ситуация была смоделирована путем физического отключения соединения: просто отсоединив шнур от клиентской машины. Я пытался воссоздать это, но с тех пор одна и та же машина всегда красиво теряет статус синхронизации после 5-6 неудачных опросов.
Реальный вопрос: что именно определяет статус синхронизации при потере соединения?
В RFC-1305 есть четкое объяснение регистра охвата:
Регистр достижимости сдвигается на одну позицию влево, при этом освободившийся бит заменяется нулем. Если все биты этого регистра равны нулю, вызывается процедура очистки, чтобы очистить тактовый фильтр и при необходимости повторно выбрать источник синхронизации. Если ассоциация не была настроена процедурой инициализации, ассоциация демобилизуется.
Однако RFC-1305 устарел на RFC-5905, что не так уж важно:
Затем 8-битный сдвиговый регистр p.reach в процессе опроса, описанном в разделе 13, используется для определения доступности сервера и наличия свежих данных. При отправке пакета регистр сдвигается влево на один бит, а крайний правый бит устанавливается в ноль. Когда поступают действительные пакеты, крайний правый бит устанавливается в единицу. Если регистр содержит ненулевые биты, сервер считается доступным; в противном случае он недоступен.
В разделе 13 не упоминается четкая процедура. Но все же похоже, что недоступный одноранговый узел в какой-то момент должен потерять свой статус синхронизации.
Мне удалось воссоздать синхронизированный статус с ситуацией достижения 0, чтобы убедиться, что это редко и совсем не постоянно. Потребовалось отключить «всплеск» в конфигурации серверов и разорвать соединение сразу после синхронизации.
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 20 64 177 51.137 -2.192 11.049
192.168.1.1 193.67.79.202 2 u 65 64 77 0.459 -1.818 0.922
remote refid st t when poll reach delay offset jitter
==============================================================================
*91.198.10.4 194.190.168.1 2 u 21 64 177 51.137 -2.192 11.049
+192.168.1.1 193.67.79.202 2 u - 64 177 0.449 -3.192 1.828
Досягаемость составила 177, что составляет 01111111 в двоичном формате. Так что для установления синхронизации потребовалось 7 опросов.
Тогда синхронизация была потеряна в этой позиции:
remote refid st t when poll reach delay offset jitter
==============================================================================
+91.198.10.4 194.190.168.1 2 u 574 64 0 63.846 -9.652 0.756
*192.168.1.1 193.67.79.202 2 u 553 64 0 0.449 -3.192 0.505
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 575 64 0 69.871 -10.409 0.002
192.168.1.1 193.67.79.202 2 u 554 64 0 0.449 -3.192 0.505
Когда числа немного странные, например, 64 * 9 = 576, а не 575, но я думаю, представление может быть неточным на 1 секунду. Учитывая это, для нарушения статуса синхронизации потребовалось 9 неудачных опросов.
Итак, учитывая как теорию, так и практику, похоже, что состояние, в котором источник с нулевой досягаемостью может считаться источником текущего времени, возможно, но также является редким и временным.