Имеются ли исследовательские материалы по точности NTP?

13

Насколько я знаю, точность синхронизации NTP сильно зависит от сети. Я видел некоторые цифры от 50 микросекунд до «менее одной секунды» через Интернет. Ну, это огромная разница.

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

Сказано на http://www.ntp.org/ntpfaq/NTP-s-algo.htm :

Разница во времени между сервером и клиентом составляет менее 128 мс, чтобы поддерживать синхронизацию NTP. Типичная точность в Интернете варьируется от 5 мс до 100 мс, возможно, в зависимости от сетевых задержек. Недавний опрос [2] показал, что 90% серверов NTP имеют сетевые задержки ниже 100 мс, и около 99% синхронизируются в течение одной секунды с узлом синхронизации.

С синхронизацией PPS точность на 50 мкс и стабильность ниже 0,1 PPM достижима на ПК Pentium (например, под управлением Linux).

Это что-то, но, может быть, есть более тщательный анализ по теме?

akalenuk
источник
3
Хотя я думаю, что этот вопрос вообще не требует каких-либо исследований, и на этом основании я провожу голосование - даже не ясно, ФП прочитал какой-либо материал на ntp.org - я думаю, что это законный вопрос, и я бы выступил против закрытия эта основа. Желание узнать, почему протокол будет работать так, как рекламируется, вместо слепого развертывания и надежды на лучшее, - не пустая трата времени.
MadHatter
Спасибо за обновление вопроса, я отрекся от своего отрицательного голоса. Тем не менее, вы, возможно, чувствуете, что раздражать, когда вас возвращают назад, откуда вы пришли, но если вы не скажете нам, где вы были, когда задаете вопрос, как мы можем знать? Я также отмечаю, что в самом тексте, который вы публикуете выше, есть указатель на академическую статью, в которой изучается точность NTP-серверов. Вы читали это, и если да, можете ли вы указать, почему этого было недостаточно?
MadHatter
Справедливо. Документ представляет собой 14-летний общий опрос по сети NTP. У него есть дополнительные ссылки, но все они, конечно, еще старше. Я пробовал Google Scholar и CiteSeer, но большинство ссылок принадлежат тем же Mills, и Millnar работает с девяностых годов. Я все еще просматриваю, но я немного далёк от темы, и это может занять много времени, поэтому я решил обратиться к сообществу за помощью.
Акаленюк
1
NTP не изменился, по крайней мере, за 14 лет, почему его точность значительно изменилась? Как упомянуто ниже, NTP не должен быть очень точным, он должен быть получен в течение 1 с (что, вероятно, откуда взялась эта недостаточно информированная цитата). Если вам нужна точность менее 1 мс, вам нужно использовать PTP. Я действительно не вижу никакой ценности в изучении точности того, что в очень широком развертывании делает именно то, для чего было предназначено.
Крис С
2
На самом деле, Крис, две части работы цитируемой делает ясно , что точность серверов NTP в Интернете (не сам протокол, который всегда был превосходен) имеет период с 1999 и в настоящее время. Я подозреваю, что это отчасти из-за того, что интернет лучше - задержки несколько ниже и гораздо менее изменчивы, чем когда-то, и отчасти потому, что качество серверов S1 улучшилось (в статье 1999 года говорится, что единственным наиболее распространенным источником синхронизации для серверов S1 является Часы ОС!). Я рад, что ОП задал этот вопрос, я думаю, что это стоит.
MadHatter

Ответы:

14

Никто не может гарантировать, насколько хорошо NTP будет работать в вашей сети, потому что никто не знает, насколько хорошо ваша сеть подключена к Интернету и к часовым серверам на нем. Тем не менее, согласно странице алгоритма часовой дисциплины на ntp.org

При непрерывной работе NTP-клиент в быстрой локальной сети в домашней или офисной среде может поддерживать синхронизацию номинально в течение одной миллисекунды. Когда колебания температуры окружающей среды меньше градуса Цельсия, частота тактового генератора определяется в пределах одной части на миллион (PPM), даже когда смещение собственной частоты тактового генератора составляет 100 PPM или более.

Обратите внимание, что большая, но стабильная задержка между вашей локальной сетью и тактовыми серверами в Интернете не так плохо влияет на точность, как задержка с высокой переменной величиной.

Вы не говорите, где вы получили оценки выше ('50 микросекунд до ...' ниже одной секунды ''), поэтому я не могу их комментировать, но по моему опыту 50us маловероятно, если у вас нет непосредственно подключенных тактовый источник и 1s маловероятны, если у вас нет кусочка мокрой строки, соединяющего вас с интернетом, и вы используете вышестоящие серверы в Антарктике.

Изменить : текст, который вы сейчас цитируете в своем вопросе, дает указатель на статью, в которой в 1999 году действительно было установлено, что 99% серверов ntp синхронизируются с точностью до одной секунды. К счастью, есть более поздние работы; В этой статье некоторые авторы из Федерального университета штата Парана, Бразилия, повторили эксперимент в 2005 году и обнаружили (если я правильно понимаю их рис. 1), что к северу от 99% - более, как 99,5% - серверов, теперь смещения меньше, чем 100 мс, и эти 90% имеют смещения менее 10 мс. Это очень хорошо вписывается в мой опыт (см. Выше).

Правка 2 : одна последняя морщинка: все эти исследования посвящены не тому, насколько точны локальные часы, а тому, насколько они отличаются от исходных эталонных часов. Это явно не одно и то же. Но первое непостижимо; чтобы понять, насколько неправильны ваши часы, вы должны точно знать, который час, и если бы вы знали это, почему бы вы сначала неправильно настроили свои часы? Просто имейте в виду , что эти исследования измеряют не разницу между местными часами и абсолютным временем, а между местными часами и эталонными часами.

Безумный Шляпник
источник
+1 Я также запустил пул-сервер, дрейф> 20 мс по всей стране был странным.
Крис С
9

Какую проблему ты пытаешься решить?

Решением, с которым я столкнулся в средах, требующих большей точности, чем NTP, является протокол точного времени (PTP) . Я имел это в научных вычислительных и финансовых вычислительных приложениях. Хотя есть и компромиссы .

Также см .: ptp синхронизация времени на centos6 / rhel

ewwhite
источник
4
"Какую проблему ты пытаешься решить?" Мой любимый вопрос - я задаю его все время.
mfinni
@mfinni, Когда вам нужно определить, кто из ваших клиентов первым подает заявку (например, HFT ), это помогает быть точным с вашим временем.
Pacerier
6

Несколько других вещей, которые стоит упомянуть:

  • Вам повезет получить <100 мс джиттера часов на виртуальной машине, так что все ниже для физического хоста
  • Джиттер Sub 100 мс практически неизмерим для почти любой задачи, и его легко достичь через Интернет
  • Джиттер до 30 мс может быть необходим для некоторых общих обслуживающих сред (он мне нужен был для корреляции журналов на предыдущей работе), и его легко достичь, используя NTP-серверы на том же континенте, где соединение осуществляется не через «потребительские» каналы (например, не через спутник). , ADSL, DOCSIS, GPON, UMTS / LTE / HSPA / и т. Д.)
  • Для абсолютной точности ниже вы должны установить аппаратные NTP-серверы от качественного поставщика (например, Symmetricom)
  • Локальное соглашение менее 10 мс (часто менее 1 мс) может быть легко достигнуто простым трио (можно делать с меньшими затратами, но есть причины использовать три или пять) в одном и том же центре обработки данных, достаточном практически для любого приложения, не относящегося к науке.
LapTop006
источник
5

Интерес с моей стороны: я агент Майнберга :-)

Да, NTP может достигать сквозной точности вплоть до прибл. 50 мкс (это микросекунды) джиттера, если вы синхронизируете «клиента» linux на голом железе, работающем на Chrony или ntpd, с NTP-сервером на базе Linux, управляемым GPS, локальными атомными часами или чем-то подобным.

На машине с локальным GPS (с соединением PPS) вы, вероятно, увидите смещение 0-2 микросекунды между экземпляром ntpd, работающим в ОС, и входом его драйвера PC для повторной синхронизации.

Те оставшиеся 50 "сквозных по локальной сети" являются результатом нескольких этапов буферизации, переменной задержки IRQ, другого трафика, мешающего в локальной сети и на задействованных компьютерных шинах и еще много чего. 50 us означает локальную сеть с очень небольшим трафиком. Даже один коммутатор может добавить несколько микросекунд джиттера, а более дорогие коммутаторы со сложными функциями увеличивают задержку и джиттер. Другими словами, может быть довольно сложно достичь этих 50 микросекунд в реальных условиях в некоторой практической локальной сети.

Точно так же эти cca <2us смещения PPS являются результатом только неопределенности задержки IRQ и общего джиттера задержки шины на аппаратном обеспечении ПК с хорошим поведением.

Обратите внимание, что NTP и его реализации ntpd и Chrony, безусловно, измеряют время прохождения транзакции NTP и вычитают (добавляют, фактически) половину этого прохождения, как меру, чтобы отфильтровать систематическую задержку передачи (в одну сторону). Они также выполняют отклонение выбросов, консенсус по кворуму, выборы syspeer и любой демон NTP фильтрует ответы, которые он получает на свои исходящие запросы. Как уже говорили другие, миллисекунды, которые вы видите в Ping и Traceroute, напрямую не смещают ваши локальные часы. Важна изменчивость транзакции в обоих направлениях, то есть другого трафика на пути к вышестоящему NTP-серверу. Ntpq -p твой друг.

Базовый приемник GPS для использования по времени с TCXO может иметь 100-200 нс остаточного джиттера + блуждания на своем выходе PPS. Достаточно хорошо для NTP, пока GPS остается заблокированным. (Производительность удержания не очень хорошая с TCXO.) Качественное время GPS с OCXO может быть в пределах 100 нс, может быть, больше, как 10-30 нс остаточной ошибки (смещение от глобального UTC).

Обратите внимание, что настоящие спутники, летящие над головой и излучающие лучи в атмосфере, могут быть немного сложнее для приемника, чем тестирование в лаборатории с генератором GPS.

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

Чип i210 - это чудо. Он имеет 4 контакта общего назначения, которые можно использовать для ввода или вывода сигнала PPS. Эталонная плата Intel NIC для плат расширения с i210 (и ее OEM-версии от нескольких крупных производителей) оснащена контактным разъемом, который дает вам доступ по крайней мере к двум из этих контактов GPIO (SDP, которые они называют Intel). Помимо реализации порта PTP-гроссмейстера, вход PPS может быть использован для точной отметки времени при захвате пакета. Вам нужен точный источник PPS и специальное программное обеспечение для запуска серво цикла, для точной настройки PHC i210 до ext.PPS. На моем испытательном стенде это привело к единственной цифре ns (за 1 итерацию) остаточного смещения. Это точность, которую вы затем получаете в своих временных метках захвата, если вы используете последнюю версию tcpdump или wireshark на современном ядре Linux (все программное обеспечение нуждается в поддержке разрешения наносекундного уровня). Еще лучше: я прошел весь путь и создал простой синтезатор PLL, чтобы производить 25 МГц для тактовых импульсов NIC, привязанных к точному исходному эталонному сигналу 10 МГц. После этого остаточное смещение в контуре сервомотора моей установки захвата пакетов упало до чистого 0 (доказательство того, что моя опорная частота 10 МГц синхронизирована по фазе с PPS из того же блока GPS).

Обратите внимание, что гроссмейстеры PTP могут быть указаны для предоставления временных меток с фактической гранулярностью за 8 нс (в типе данных с разрешением 1 нс). Это имеет смысл - гигабитный Ethernet имеет тенденцию использовать тактовую частоту 125 МГц, используемую в качестве байтовой тактовой частоты во внутренних элементах MAC, эта тактовая частота, вероятно, также используется в GMII, и это также символьная тактовая частота в металлическом 1000Base-TX (четыре пары параллельно, 2 бита на символ на пару). Поэтому, если вы не используете 1000Base-FX (оптоволокно) с SERDES и экстремистскую реализацию модуля метки времени HW в PHY, который работает до отдельных битов SERDES, эти 8 нс - это все, на что вы можете реально надеяться в гигабитном Ethernet. Некоторые таблицы данных микросхем (с поддержкой PTP) даже утверждают, что путь данных MII не свободен от буферизации, и оттуда может возникнуть некоторое дрожание.

Пакеты PTP на самом деле содержат временные метки, хранящиеся в типе данных, который допускает глубокое субнаносекундное разрешение. Но «субнаносекундное дробное поле» в настоящее время обычно не используется. AFAIR только в проекте White Rabbit (связанном с CERN, швейцарским исследовательским центром) до сих пор реализована точность до минимума.

PTP также доступен в чистом программном обеспечении, без ускорения HW. В этом случае для GM на базе SW и клиента на базе SW ожидайте остаточного дрожания, аналогичного NTP, то есть около 50 мкс в выделенной, но не PTP-локальной сети. Я вспоминаю, как получал точность до микросекунды от гроссмейстера HW по прямому межсоединению (без промежуточного коммутатора) и клиенту только для SW (на сетевой плате, не подозревающей на PTP). По сравнению с NTP сервопривод PTP сходится намного быстрее.

Выполняя некоторую «домашнюю работу», недавно мне пришло в голову, что транспортировка PPS или подобных «дискретных» сигналов синхронизации по глобальным оптоволоконным маршрутам может быть подвержена зависящему от температуры распространению «блуждающего» времени распространения. И хотя у меня нет возможности проверить это экспериментально, некоторые источники в интервалах приводят цифры от 40 до 76 пикосекунд на км и Кельвина. Следует отметить, что хотя этот вид «теплового блуждания» невозможно смягчить «в полосе» при симплексной передаче PPS, PTP посткомпенсирует это по своей природе на основе своих стандартных измерений задержки в тракте (что зависит от полнодуплексной передачи).

Так много для обзора того, как выглядят «прецизионности» для различных технологий синхронизации / интерфейсов. Какой уровень точности достаточно хорош для вас, это зависит от вашего приложения, от ваших реальных потребностей.

ФПП
источник