Я никогда не использовал ntpstat
(это не стандартная установка в debian/ubuntu), но много лет использовал ntp и обычно смотрю на вывод ntpq -nc peer
или ntpq -np
который, вероятно, показывает похожую информацию. ntpq
показывают положительные и отрицательные значения.
По сути, если ntp(stat) говорит, что он синхронизирован (или вывод ntpq помечает сервер как «*»), то он настолько близок, насколько это возможно, но он будет продолжать пытаться и улучшаться.
Упрощенное объяснение работы NTP состоит в том, что он регулярно отправляет пакеты на серверы времени, содержащие временную метку времени, которое локальная машина считает. Затем сервер добавляет свою метку времени и возвращает пакет на локальный компьютер. Как только он прибывает, у локальной машины есть 3-я отметка времени, время прибытия. Предполагая, что пакету потребовалось одно и то же время, чтобы добраться до сервера и вернуться, NTP может определить, какое было время на локальной машине, когда сервер добавил свою временную метку, и, следовательно, может вычислить разницу и внести корректировку.
Сетевые пакеты обычно достигают нескольких десятков миллисекунд, чтобы добраться до сервера и вернуться. Из-за различий в сетевом трафике время исходящего и входящего транзита может не совпадать, но определить это невозможно, поэтому NTP должен предположить, что они совпадают. В результате NTP никогда не сможет приблизиться к точной синхронизации ближе, чем на несколько миллисекунд, и объявит синхронизацию, когда временные метки отправления и получения ограничат временную метку сервера.
Даже при синхронизации NTP будет продолжать обмениваться пакетами и пытаться настроить время, чтобы минимизировать разницу во времени. Это делается путем небольших корректировок (фактически путем небольшого увеличения или уменьшения количества тактов в секунду), чтобы не было внезапных скачков и чтобы избежать проблем из-за сетевых аномалий.
Поэтому, когда ntpstat
говорит, что он синхронизируется, он как можно ближе, но он дает лучшую оценку того, насколько далеко он может быть.