Казалось бы, низкое качество синхронизации времени NTP с использованием часов GPS
У меня есть сервер Linux, время которого синхронизировано с устройством NTP на базе GPS, расположенным рядом. Время пинга от сервера к устройству составляет около 1 мс с очень низким дрожанием:
--- хххх пинг статистика --- 100 переданных пакетов, 100 принятых, потеря пакета 0%, время 99001мс rtt мин / среднее / макс /mdev = 0,874/0,957/1,052/0,051 мс
Тем не менее, клиент NTP оценивает точность синхронизации времени примерно в 5-6 мс, что кажется очень высоким, учитывая настройку:
синхронизируется с сервером NTP (xxxx) в страте 2 время с точностью до 5 мс опрос сервера каждые 16 с
ntpq -p дает следующее:
дистанционный refid st t, когда опрос достигает задержки смещения джиттера ============================================================================== * хххх.PPS. 1 u 10 16 377 0,964 -0,019 0,036
Два вопроса:
- Что может быть причиной того, что у клиента NTP такая низкая уверенность в точности синхронизации?
- Есть ли способ измерить фактическую точность синхронизации, скажем, с точностью до миллисекунды?
3 ответа
Значение, которое ntpstat отображается после "правильное время с точностью до" - дисперсия корня + задержка корня / 2. ntpq -p не показывает прогон "корневая дисперсия" ntpq -c rl вместо.
Несмотря на это, ясно, что основным источником отсутствия точности является дисперсия, а не задержка (которая составляет всего 0,964).
Дисперсия представляет собой "номинальную погрешность относительно первичного эталонного источника". Я кратко рассмотрел NTPv4 RFC, и вот что он должен сказать:
Дисперсия (эпсилон) представляет собой максимальную ошибку, присущую измерению. Он увеличивается со скоростью, равной максимальному допустимому отклонению тактовой частоты системы (PHI), обычно 15 PPM. 1 стр / мин равна 10^(-6) секунд в секунду.
Использование терминологии rrdtool - это не показатель, а счетчик. Просмотр большого значения может не указывать на то, что что-то не так.
Увы, я не смог понять алгоритм ntp достаточно хорошо, чтобы понять, как уменьшить это число. Я заметил, что это значение иногда сбрасывается. Я не знаю почему.
Причина, по которой я спросил об оборудовании выше, заключается в том, что многие устройства GPS (уровень 0, "корневой" источник) подключаются к компьютеру, который затем работает как NTP-сервер через последовательную связь.
Последовательные соединения часто имеют дрожание 1-5 мс на линии из-за служебных сигналов / ожиданий прерывания. Следовательно, я предполагаю, что ваш источник NTP читает из последовательного источника.
Существуют некоторые настройки, которые вы можете выполнить на последовательном соединении, чтобы уменьшить дрожание. Прежде всего, отключение FIFO может дать вам приличные результаты.
http://support.ntp.org/bin/view/Support/KnownHardwareIssues. http://www.febo.com/time-freq/ntp/jitter/index.html
Время, правильное в течение 5 мс, ОТЛИЧНО!!! 5 мс - 5 / 1000 секунды. Все, что меньше 100 мс, легко приемлемо для чего-либо, кроме небольшого числа ситуаций, в этом случае вы будете использовать не GPS, а локальные атомные часы и два внешних опорных часа. Мы получаем в течение 10 мс с пулом NTP.