Я виявляв інтерес з мого боку: я агент Майнберга :-)
Так, NTP може досягти точності від кінця до приблизно. 50 нас (це мікросекунди) джиттера, якщо ви синхронізуєте "клієнт" Linux на голому металі під керуванням Chrony або ntpd, на сервері NTP на базі Linux, дисциплінованому GPS, локальним атомним годинником або яким-небудь таким джерелом.
На машині, яка має локальний GPS (з підключенням PPS), ви, мабуть, побачите зміщення 0-2 мікросекунди між екземпляром ntpd, що працює в ОС, і входом драйвера PPS reflock.
Ці залишкові 50 нас "від кінця до кінця через локальну мережу" є результатом декількох етапів буферизації, змінної затримки IRQ, іншого втручання трафіку в локальну мережу та залучених комп’ютерних шин і багато чого іншого. 50 нас означає мережу з дуже невеликим трафіком. Навіть просто перемикач може додати кілька мікросекунд джиттера - а вищі комутатори зі складними функціями додають більше затримки та тремтіння. Іншими словами, досягти цих 50 мікросекунд у ваших реальних умовах в деяких практичних локальних мережах може бути досить важко.
Аналогічно, ці cca <2us зсуву PPS є результатом просто невизначеності затримки IRQ та загального тремтіння затримки в шині на добре поводячомусь апаратному забезпеченні ПК.
Зауважте, що NTP та його реалізація ntpd та Chrony, безумовно, вимірюють час трансляції NTP транзакцій та віднімають (додають насправді) половину цієї туди-назад, як міру відфільтрувати систематичну транспортну затримку (в один бік). Вони також виконують відхилення від зовнішнього вигляду, домовленість про кворум, вибори системи та будь-який демон NTP фільтрує відповіді, які він отримує на свої upstream запити. Як уже говорили інші, мілісекунди, які ви бачите в Ping і Traceroute, не компенсують ваш місцевий годинник безпосередньо. Важливим є мінливість зворотної транзакції транзакцій, тобто іншого трафіку на шляху до вашого поточного сервера NTP. Ntpq -p - твій друг.
Основний GPS-приймач для використання в режимі синхронізації, з TCXO, може мати 100-200 нс залишкового тремтіння + блукання на своєму виході PPS. Досить добре для NTP, поки GPS залишається заблокованим. (Продуктивність Holdover не дуже хороша для TCXO.) Якість GPS синхронізації з OCXO може бути в межах 100 нс, можливо, більше, ніж 10-30 нс залишкової помилки (зміщення від глобального UTC).
Зауважте, що фактичні супутники, що летять над головою та промінькують на вас через атмосферу, можуть бути трохи жорсткішою грою для приймача, ніж тестування в лабораторії з генератором GPS.
ПТП - молоток. Вам потрібна підтримка HW у гросмейстера, і у рабів, і в будь-яких комутаторах, - але якщо ви все це отримаєте, можливі залишкові зсуви до низьких двозначних наносекунд. Я особисто бачив це в ptp4l, що працює з i210 NIC, який має підтримку HW (мітка часу з наносекундною роздільною здатністю).
Чіп i210 - це диво. Він має 4 штифта загального призначення, які можна використовувати для введення або виведення сигналу PPS. Довідкова плата Intel addon NIC з i210 (і її версії OEM від декількох великих постачальників) оснащена штифтовим заголовком, який надає вам доступ до щонайменше двох цих штифтів GPIO (SDP називають Intel). Окрім впровадження порту великого майстра PTP, вхід PPS можна використовувати для точного позначення часу при захопленні пакетів. Вам потрібне точне джерело PPS та спеціальний фрагмент програмного забезпечення, щоб запустити серво цикл, точно налаштувавши PHC i210 на ext.PPS. На моїй тестовій установці це призвело до однозначної ns (за 1 с ітерації) залишкового зміщення. Це точність, яку ви отримуєте в часових мітках захоплення, якщо ви запустите нещодавній tcpdump або wireshark на сучасному ядрі Linux (все програмне забезпечення потребує підтримки для вирішення наносекундного рівня). А ще краще: я пройшов увесь шлях і створив простий синтезатор PLL для створення 25 МГц для NIC-годинників, зафіксованих до точної 10MHz-посилання. Після цього залишковий зсув у контурі сервоприводу моєї установки захоплення пакетів знизився до чистого 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 фактично містять часові позначки, що зберігаються у типі даних, що дозволяє отримати глибоку субнаносекундну роздільну здатність. Але "субнаносекундне дробове поле" в наш час зазвичай не використовується. ПІСЛЯ тільки проект «Білий кролик» (пов'язаний із швейцарським дослідницьким центром «ЦЕРН») до цих пір здійснив точність підрядів.
PTP також доступний у чистому програмному забезпеченні, без прискорення HW. У цьому випадку, для GM на базі SW та клієнта, що базується на SW, розраховуйте отримати аналогічний залишковий тремтіння, як і для NTP - тобто близько 50 нас у спеціальній, але не відомій для PTP локальній мережі. Я пам’ятаю, що отримував субмікросекундну точність від великого майстра HW за прямим взаємозв’язком (без переключення між ними) та клієнтом, що працює лише на SW (на ПК, що не знає ПК PIC). У порівнянні з NTP, сервоприймач PTP зближується набагато швидше.
Виконуючи деякі "домашні завдання", мені нещодавно прийшло в голову, що транспортування PPS або подібних "дискретних" сигналів синхронізації по широкосмугових волоконно-оптичних маршрутах може бути сприйнятливим до залежного від температури часу "поширення". І хоча я не маю можливості це експериментально перевірити, деякі джерела в інтерверті наводять цифри від 40 до 76 пікосекунд на км і Кельвіна. Зауважте, що хоча подібного типу "теплової блукання" неможливо пом'якшити "в смузі" в симплексній передачі PPS, PTP поступово це компенсує, грунтуючись на стандартних вимірюваннях затримки шляху (що залежить від повної дуплексної передачі).
Отож, для огляду того, як виглядають "точності", за різних технологій / інтерфейсів хронометражу. Який рівень точності вам достатньо хороший, це залежить від вашої заявки, від ваших реальних потреб.