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

Насколько я знаю, точность синхронизации 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, 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 посткомпенсирует это по своей природе на основе своих стандартных измерений задержки в тракте (что зависит от полнодуплексной передачи).

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