Обычно, когда машина полностью теряет соединение, ntpd пропускает пару опросов и помечает все источники как несостоявшиеся. Что кажется вполне логичным. Но я сталкивался с ситуацией, когда сервер оставался помечен как текущий источник времени, в то время как его доступность равнялась 0.
Sever развернут в той же подсети, что и целевая машина, обеспечивая очень низкую задержку, смещение и джиттер. Ситуация была смоделирована путем физического отключения соединения: просто отсоединением кабеля от клиентской машины. Я пытался воссоздать это, но с тех пор та же машина всегда красиво теряет статус синхронизации после 5-6 неудачных опросов.
Настоящий вопрос заключается в следующем: что именно определяет состояние синхронизации при потере соединения?
решение1
В RFC-1305 имеется четкое объяснение по поводу регистра охвата:
Регистр достижимости сдвигается на одну позицию влево, заменяя освобожденный бит нулем. Если все биты этого регистра равны нулю, вызывается процедура очистки для очистки фильтра часов и повторного выбора источника синхронизации, если это необходимо. Если ассоциация не была настроена процедурой инициализации, ассоциация демобилизуется.
Однако RFC-1305 устарел из-за RFC-5905, который не так уж и важен:
Далее 8-битный регистр сдвига p.reach в процессе опроса, описанном в разделе 13, используется для определения доступности сервера и свежести данных. Регистр сдвигается влево на один бит при отправке пакета, а самый правый бит устанавливается в ноль. По мере поступления допустимых пакетов самый правый бит устанавливается в единицу. Если регистр содержит какие-либо ненулевые биты, сервер считается доступным; в противном случае он недостижим.
В разделе 13 не указано никакой четкой процедуры. Но все равно похоже, что недоступный одноранговый узел должен в какой-то момент потерять свой статус синхронизации.
Мне удалось воссоздать синхронизированный статус с ситуацией reach 0, чтобы убедиться, что это редкое и совсем не постоянное явление. Потребовалось отключить "burst" в конфигурации серверов и разорвать соединение сразу после синхронизации.
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 неудачных опросов, чтобы сломать статус синхронизации.
Таким образом, принимая во внимание как теорию, так и практику, можно сделать вывод, что состояние, при котором источник с нулевой досягаемостью можно считать текущим источником времени, возможно, но также редко и временно.