Запрос источника текущего времени NTP

У меня есть вопрос относительно ntpd варианты и ntpq команда.

Я установил локальный NTP-сервер на ПК с Ubuntu 14.04, а NTP-клиент - это настраиваемая платформа разработки, основанная на Renesas RZ / G1H.

Я запустил NTP на своем сервере NTP и ntpd работает на NTP-клиенте.

В настоящее время мой NTP-клиент синхронизируется с NTP-сервером. Я побежал ntpq чтобы подтвердить, что:
```
remote          refid       st t      when    poll    reach      delay      offset     jitter
*192.168.4.98   LOCAL(0)    11 u      -      64        1         0.282     -0.008      0.029
LOCAL(0)       .LOCL.       14 l      -      64        0         0.000      0.000      0.000
```
Как вы видете, 192.168.4.98 это мой NTP-сервер, и на нем отображается текущий источник времени (*).
Я изменил дату на сервере NTP (ПК с Ubuntu), используя date команда.

Тогда я бежал ntpq постоянно на стороне клиента NTP для отслеживания изменений. В какой-то момент звездочка не отображалась. Ниже приведен вывод ntpq:

remote          refid       st t      when    poll    reach      delay      offset     jitter
192.168.4.98    LOCAL(0)    11 u      -      64        1         0.282     -0.008      0.029
LOCAL(0)       .LOCL.       14 l      -      64        0         0.000      0.000      0.000

Затем примерно через 5 минут звездочка отобразилась рядом с LOCAL(0) как это:

remote          refid       st t      when    poll    reach      delay      offset     jitter
192.168.4.98    LOCAL(0)    11 u      -      64        1         0.282     -0.008      0.029
*LOCAL(0)       .LOCL.      14 l      -      64        0         0.000      0.000      0.000

Затем примерно через 10 минут звездочка снова загорелась. 192.168.4.98 что означает, что клиент запущен для синхронизации с NTP-сервером.

Почему рядом с LOCAL(0) между ними, прежде чем он вернулся к IP-адресу NTP-сервера?

Ваши примеры не совсем точны ntpq вывод, и все они выглядят точно так же, за исключением * код tally, который предполагает, что они редактируются на основе одного и того же запроса, а не на реальных примерах того времени, когда это произошло. Поэтому я могу только предполагать, что произошло, основываясь на вашем описании процесса.

Общий ответ на ваш вопрос: NTP перестанет использовать источник, если у него есть основания полагать, что он обслуживает неправильное время.

Когда вы изменили дату на своем сервере NTP (предположительно более чем на 1 секунду), ваш клиент NTP заметил бы это как большой скачок времени со стороны сервера NTP. Итак, источник 192.168.4.98 сильно изменилось, в то время как LOCAL(0) источник на клиенте изменился на более предсказуемую величину. Так ntpd на вашем клиенте отметили бы 192.168.4.98 так плохо, затем потребовалось немного времени, чтобы выбрать новый источник и выбрать LOCAL(0). После того, как NTP-сервер какое-то время работал стабильно, клиент переключился бы обратно, поскольку LOCAL(0) источник ни с чем не синхронизировался, и 192.168.4.98 был нижним слоем.

Ваша общая конфигурация плохая, и вы делаете ряд вещей, которые противоречат лучшая практика:

Использование устаревшего драйвера LOCAL вместо получения времени по хорошим эталонным часам
Использование только одного источника времени

NTP не предназначен для работы изолированно. В конце концов, все время должно исходить из авторитетного источника слоя 0. Большинство людей получают свое время от Пул NTP, который использует набор различных источников (но часто GPS). Используя ЛОКАЛЬНЫЙ драйвер, вы зависите от того, насколько плохо работает ваш локальный тактовый генератор (спойлер: обычно довольно плохо).

Вы, вероятно, сможете получить примерно то поведение, которое хотите для тестирования, удалив ЛОКАЛЬНЫЙ драйвер из вашего NTP-клиента. Но не делайте этого, если вы заботитесь о точности времени. Прочтите Лучшие текущие практики NTP, то Документация NTP, или моя серия блогов чтобы узнать больше о хорошей конфигурации NTP.