Синхронизация NTP остается без досягаемости

В 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 неудачных опросов, чтобы нарушить статус синхронизации.

Итак, учитывая как теорию, так и практику,