Насколько мне известно, точность синхронизации 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 маловероятно, если у вас нет напрямую прикрепленного тактовый источник, и единицы маловероятны, если у вас есть кусок влажной струны, соединяющий вас с Интернетом, и вы не используете вышестоящие серверы в Антарктиде.
редактировать: текст, который вы сейчас цитируете в своем вопросе, указывает на статью, в которой в 1999 году действительно было установлено, что 99% серверов ntp синхронизируются с точностью до одной секунды. К счастью, есть более свежие работы; в Эта бумага некоторые авторы из Федерального университета Параны, Бразилия, повторили эксперимент в 2005 году и обнаружили (если я правильно понимаю их рис. 1), что к северу от 99% - больше похоже на 99,5% - серверов теперь есть смещения менее 100 мс, и что 90% имеют смещение менее 10 мс. Это очень хорошо согласуется с моим опытом (см. Выше).
Редактировать 2: последняя морщинка: все эти исследования не исследуют, насколько точны локальные часы, а вместо этого исследуют, насколько они отличаются от опорных часов восходящего направления. Это явно не одно и то же. Но первое непостижимо; чтобы знать, насколько неправильные ваши часы, вы должны точно знать, сколько они времени, и если бы вы знали это, почему бы вы вообще неправильно установили часы? Просто имейте в виду, что эти исследования измеряют не разница между местными часами и абсолютным временем, но между местными часами и эталонными часами.
Какую проблему ты пытаешься решить?
Решение, с которым я столкнулся для сред, требующих большей точности, чем NTP, - это Протокол точного времени (PTP). У меня это было в приложениях для научных вычислений и финансовых вычислений. Есть компромиссы, хотя.
Стоит упомянуть еще несколько вещей:
Я очень заинтересован: я агент Майнберга :-)
Да NTP может обеспечить сквозную точность до прибл. 50 мкс (это микросекунды) джиттера, если вы синхронизируете «клиент» Linux на голом железе, работающий под управлением Chrony или ntpd, с сервером NTP на базе Linux, управляемым GPS, локальными атомными часами или каким-либо подобным источником.
На машине с локальным GPS (с межсоединением PPS) вы, вероятно, увидите смещение в 0–2 микросекунды между экземпляром ntpd, запущенным в ОС, и входом его драйвера PPS refclock.
Эти оставшиеся 50 мкс «сквозной связи по локальной сети» являются результатом нескольких этапов буферизации, переменной задержки прерывания прерывания, другого трафика, создающего помехи в локальной сети и задействованных компьютерных шинах, и т. Д. 50 мкс означает ЛВС с очень небольшим трафиком. Даже простой коммутатор может добавить несколько микросекунд джиттера, а коммутаторы более высокого уровня со сложными функциями добавляют больше задержки и дрожания. Другими словами, может быть довольно сложно достичь этих 50 микросекунд в реальных условиях в некоторой практической локальной сети.
Точно так же эти cca <2us смещения PPS являются результатом только неопределенности задержки IRQ и общего джиттера задержки шины на исправном оборудовании ПК.
Обратите внимание, что NTP и его реализации ntpd и Chrony, безусловно, измеряют время прохождения транзакции NTP туда и обратно и вычитают (фактически добавляют) половину этого цикла туда и обратно, чтобы отфильтровать систематическую задержку транспорта (в одну сторону). Они также выполняют отклонение выбросов, согласование кворума, выборы системного сервера, и любой демон NTP фильтрует ответы, которые он получает на свои восходящие запросы. Итак, как говорили другие, миллисекунды, которые вы видите в Ping и Traceroute, не напрямую смещают ваши локальные часы. Что важно, так это вариативность кругового пути транзакции, то есть другого трафика на пути к вашему вышестоящему серверу NTP. Ntpq -p - ваш друг.
Базовый GPS-приемник для временного использования с TCXO может иметь на выходе PPS 100-200 нс остаточного джиттера + дрейф. Достаточно хорошо для NTP, пока GPS остается заблокированным. (Производительность удержания не очень хороша с TCXO.) Качество синхронизации GPS с OCXO может быть в пределах 100 нс, может быть больше похоже на 10-30 нс остаточной ошибки (смещение от глобального UTC).
Обратите внимание, что настоящие спутники, летающие над головой и излучающие на вас через атмосферу, могут быть немного более сложной игрой для приемника, чем тестирование в лаборатории с помощью генератора GPS.
ПТП - это молоток. Вам нужна аппаратная поддержка в грандмастере, в подчиненных устройствах и в любых коммутаторах - но если вы все это получите, возможны остаточные смещения до низких двузначных цифр наносекунд. Я лично видел это в ptp4l, работающем с сетевой картой i210, которая имеет поддержку HW (временные метки с наносекундным разрешением).
Чип i210 - это чудо. Он имеет 4 контакта общего назначения, которые можно использовать для ввода или вывода сигнала PPS. Эталонная плата Intel addon NIC с i210 (и ее OEM-версиями от нескольких крупных поставщиков) оснащена штыревым разъемом, который дает вам доступ как минимум к двум из этих контактов GPIO (Intel называет их SDP). Помимо реализации порта грандмастера PTP, вход PPS может быть использован для точной отметки времени при захвате пакетов. Вам нужен точный источник PPS и специальное программное обеспечение для запуска сервоконтура, точной настройки PHC i210 для ext.PPS. На моем испытательном стенде это привело к однозначному значению нс (на итерацию в 1 с) остаточного смещения. Это точность, которую вы затем получаете в своих временных метках захвата, если вы запускаете последнюю версию tcpdump или wirehark на современном ядре 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, швейцарским исследовательским центром) до сих пор реализовал точность sub-ns.
PTP также доступен в чистом программном обеспечении без аппаратного ускорения. В этом случае для GM на основе SW и клиента на основе SW ожидайте получить такой же остаточный джиттер, что и в случае с NTP, то есть около 50 мкс в выделенной, но не поддерживающей PTP LAN. Я вспоминаю, как получал субмикросекундную точность от HW grandmaster по прямому межсоединению (без переключения между ними) и SW-клиенту (на NIC ПК, не знающем PTP). По сравнению с NTP сервопривод PTP сходится намного быстрее.
Выполняя некоторую «домашнюю работу», недавно мне пришло в голову, что транспортировка PPS или подобных «дискретных» сигналов синхронизации по широкополосным оптоволоконным маршрутам может быть подвержена влиянию температурно-зависимого «блуждания» времени распространения. И хотя у меня нет возможности проверить это экспериментально, некоторые источники в сети приводят цифры от 40 до 76 пикосекунд на км и градуса Кельвина. Обратите внимание, что хотя этот вид «теплового блуждания» невозможно уменьшить «внутри полосы» при симплексной передаче PPS, PTP будет посткомпенсировать это по своей сути, основываясь на своих стандартных измерениях задержки пути (которая зависит от полнодуплексной передачи).
Это достаточно для обзора того, как выглядят "точности" при различных технологиях синхронизации / интерфейсах. Какой уровень точности вам подходит, это зависит от вашего приложения, от ваших реальных потребностей.