Насколько точно можно ожидать время от сервера NTP уровня 0 в той же подсети в сети Ethernet? - PullRequest
4 голосов
/ 24 сентября 2008

У меня есть приложение, которое зависит от gpsd и ntpd для точной установки системного времени на компьютере с Linux.

gpsd подается NMEA + PPS

Приложение перелистывает ~ 25 МБ в секунду по сети, и я думаю, что загрузка системы как-то вызывает дрожание во времени. (загруженная шина PCI Express вызывает нерегулярную задержку прерывания)

У меня есть другая машина, которая вообще не загружена, и которую я могу настроить для чтения GPS и работы в качестве NTP-сервера для загруженной машины. (загруженная машина получит startum 1 ???)

Насколько точно можно ожидать времени от NTP-сервера уровня 0 в той же подсети Ethernet?

Я надеюсь, что это не слишком не по теме, я уверен, что когда-нибудь кто-то будет рад, ответ задокументирован здесь. ; -)

Ответы [ 3 ]

4 голосов
/ 24 сентября 2008

Лучшая информация, которую я мог найти о Точность NTP , кажется, указывает на 1-2 мс при настройке локальной сети:

NTP v4 с модами ядра для его поддержки, имеет гораздо лучшую точность, чем 1 мс, а возможно, и 1 нс. Согласно статье [Dave Mills], NTP v3 с точностью до 1-2 мс в локальной сети и 10 с мс в сетях WAN. http://www.cis.udel.edu/~mills/ntp.html

Другие статьи предполагают, что с точным источником времени, таким как источник времени GPS, NTP с точностью до 50 мкс, но ссылки на поддержку ядра Linux говорят, что возможна точность в несколько мс. http://www.atomic -clock.galleon.eu.com / support / ntp-time-server-precision.html

В другой статье говорится, что это зависит от предсказуемости сетевых задержек (то есть сети с низким уровнем джиттера). http://www.postel.org/pipermail/end2end-interest/2003-April/002925.html

2 голосов
/ 24 сентября 2008

NTP обычно считается хорошим для небольших однозначных мс в такой ситуации.

После того, как он работал в течение нескольких дней, на самом деле не должно быть большого джиттера ни на одном из реальных часов, потому что ntpd реализует кучу очень длительной фильтрации с постоянным временем.

Однако вы на самом деле не говорите, как измеряете время, и какой бы механизм вы ни использовали, он может быть таким же нервным, как (если не больше, чем) основной синхронизации.

Если у вас занятая сеть и сетевые карты с очень глубокой буферизацией, то это может не помочь, поскольку дрожание между прибытием пакета и обработкой прерывания будет больше. Чем шире коммутация Ethernet, тем хуже для синхронизации - старомодные концентраторы в этом отношении лучше, чем коммутаторы.

0 голосов
/ 22 марта 2013

Уровень страты рассматриваемого NTP-сервера не имеет отношения к точности часов / сервера. Это просто означает расстояние от «опорных часов», которыми вы являетесь.

Что еще важнее в отношении точности NTP (во времени, конечно), так это задержки в сети между серверами, тип используемого сервера и, возможно, нагрузка на сервер. В зависимости от того, какой NTP-сервер вы используете, они документируют, насколько точным будет их время. Каждое серверное программное обеспечение использует различные алгоритмы для вычисления времени на основе задержки в сети и нагрузки на сервер, и это сводится к точности этих алгоритмов.

Например, сервер MS NTP заявляет, что он будет точным в течение 2 секунд. OpenNTPd заявил, что они не дадут вам возможную точность сервера. В некоторых случаях серверы уровня 3 могут быть более точными, чем серверы уровня 2 и т. Д.

...