Intérêt de ma part: je suis un agent de Meinberg :-)
Oui, NTP peut atteindre une précision de bout en bout jusqu'à env. 50 us (c'est microsecondes) de gigue, si vous synchronisez un "client" linux sur du métal nu exécutant Chrony ou ntpd, à un serveur NTP basé sur Linux discipliné par un GPS, une horloge atomique locale ou une telle source.
Sur la machine qui a un GPS local (avec une interconnexion PPS), vous verrez probablement 0-2 microsecondes de décalage, entre l'instance ntpd s'exécutant dans le système d'exploitation et l'entrée du pilote de son horloge PPS.
Ces 50 us résiduels "de bout en bout sur un LAN" sont le résultat de plusieurs étapes de mise en mémoire tampon, de latence IRQ variable, d'autres trafics interférant sur le LAN et sur les bus informatiques impliqués et ainsi de suite. 50 us signifie un LAN avec très peu de trafic. Même un simple commutateur peut ajouter quelques microsecondes de gigue - et les commutateurs haut de gamme avec des fonctionnalités complexes ajoutent plus de latence et de gigue. En d'autres termes, il peut être assez difficile d'atteindre ces 50 microsecondes dans vos conditions réelles sur un réseau local pratique.
De même, ces cca <2us du décalage PPS résultent uniquement de l'incertitude de latence IRQ et de la gigue de latence de bus générale sur du matériel PC bien comporté.
Notez que NTP et ses implémentations ntpd et Chrony mesurent certainement le temps d'aller-retour des transactions NTP et soustraient (ajoutent, en fait) la moitié de cet aller-retour, comme mesure pour filtrer la latence de transport systématique (à sens unique). Ils effectuent également le rejet des valeurs aberrantes, le consensus de quorum, l'élection de syspeer et tout démon NTP filtre les réponses qu'il obtient à ses requêtes en amont. Ainsi, comme d'autres l'ont dit, les millisecondes que vous voyez dans Ping et Traceroute ne décalent pas directement votre horloge locale. Ce qui importe, c'est la variabilité de l'aller-retour des transactions, c'est-à-dire d'autres trafics sur le chemin vers votre serveur NTP en amont. Ntpq -p est votre ami.
Un récepteur GPS de base pour le chronométrage, avec un TCXO, peut avoir entre 100 et 200 ns de gigue résiduelle + dérapage sur sa sortie PPS. Assez bien pour NTP, tant que le GPS reste verrouillé. (Les performances de maintien ne sont pas très bonnes avec les TCXO.) Un GPS de synchronisation de qualité avec un OCXO peut être bien à moins de 100 ns, peut-être plus comme 10-30 ns d'erreur résiduelle (décalé de l'UTC global).
Notez que les satellites réels volant au-dessus de vous et rayonnant dans une atmosphère peuvent être un jeu légèrement plus difficile pour le récepteur que le benchmarking dans un laboratoire avec un générateur GPS.
PTP est un marteau. Vous avez besoin du support HW dans le grand maître, et dans les esclaves, et dans tous les commutateurs - mais si vous obtenez tout cela, des décalages résiduels vers le bas à deux chiffres de nanosecondes sont possibles. J'ai personnellement vu cela dans ptp4l fonctionnant avec une carte réseau i210 qui prend en charge HW (horodatage avec une résolution en nanosecondes).
La puce i210 est une merveille. Il dispose de 4 broches à usage général qui peuvent être utilisées pour entrer ou sortir un signal PPS. La carte NIC addon Intel de référence avec i210 (et ses versions OEM de plusieurs grands fournisseurs) est équipée d'un en-tête de broche qui vous donne accès à au moins 2 de ces broches GPIO (SDP, elles sont appelées par Intel). En plus d'implémenter un port grand maître PTP, l'entrée PPS peut être utilisée pour un horodatage précis dans la capture de paquets. Vous avez besoin d'une source précise de PPS et d'un logiciel personnalisé pour exécuter une boucle d'asservissement, affinant le PHC de l'i210 sur le PPS ext. Sur mon banc d'essai, cela a entraîné un ns à un chiffre (par itération de 1 s) de décalage résiduel. C'est la précision que vous obtenez alors dans vos horodatages de capture, si vous exécutez un tcpdump ou un wirehark récent sur un noyau Linux moderne (tous les logiciels doivent prendre en charge la résolution au niveau nanoseconde). Mieux encore: je suis allé jusqu'au bout et j'ai construit un simple synthé PLL pour produire 25 MHz pour les horloges NIC, verrouillé sur une référence précise de 10 MHz en amont. Après cela, le décalage résiduel dans la boucle d'asservissement de ma plate-forme de capture de paquets est tombé à un 0 propre (une preuve que ma référence à 10 MHz est synchronisée en phase avec le PPS de cette même boîte GPS).
Notez que les grands maîtres PTP peuvent être spécifiés pour fournir des horodatages avec une granularité réelle par 8 ns (dans un type de données avec une résolution de 1 ns). Cela a du sens - Gigabit Ethernet a tendance à utiliser une horloge de 125 MHz, utilisée comme horloge d'octet dans les internes du MAC, cette horloge est probablement également utilisée dans le GMII, et c'est aussi l'horloge de symbole en 1000Base-TX métallique (quatre paires en parallèle, 2 bits par symbole par paire). Donc, à moins que vous n'utilisiez 1000Base-FX (fibre optique) avec SERDES et une implémentation extrémiste de l'unité d'horodatage HW dans le PHY qui fonctionne jusqu'à des bits SERDES individuels, ces 8 ns sont tout ce que vous pouvez espérer de manière réaliste sur Ethernet gigabit. Certaines fiches de données de puce (avec prise en charge PTP) prétendent même que le chemin de données MII n'est pas exempt de mise en mémoire tampon et qu'une gigue peut en provenir.
Les paquets PTP contiennent en fait des horodatages stockés dans un type de données qui permet une résolution profonde de moins d'une nanoseconde. Mais le "champ fractionnaire sub-nanoseconde" n'est généralement pas utilisé de nos jours. AFAIR seul le projet White Rabbit (lié au CERN, le centre de recherche suisse) a mis en œuvre jusqu'à présent une précision inférieure à ns.
PTP est également disponible en logiciel pur, sans accélération matérielle. Dans ce cas, pour un GM basé sur SW et un client basé sur SW, attendez-vous à obtenir une gigue résiduelle similaire à celle de NTP - soit environ 50 us sur un LAN dédié mais sans PTP. Je me souviens avoir obtenu une précision inférieure à la microseconde d'un grand maître HW sur une interconnexion directe (pas de commutateur entre les deux) et un client SW uniquement (sur une carte réseau PC ignorant PTP). Comparé au NTP, le servo du PTP converge beaucoup plus rapidement.
Tout en faisant mes «devoirs», je me suis récemment rendu compte que le transport de PPS ou de signaux de synchronisation «discrets» similaires sur des routes à fibres optiques étendues pouvait être sensible au temps de propagation «errant» dépendant de la température. Et même si je n'ai aucun moyen de tester cela expérimentalement, certaines sources dans les interwebs citent des chiffres entre 40 et 76 picosecondes par km et Kelvin. Notez que bien que ce type de "dérapage thermique" soit impossible à atténuer "en bande" dans la transmission PPS simplex, PTP post-compenserait cela de manière inhérente, sur la base de ses mesures de retard de trajet standard (qui dépendent de la transmission en duplex intégral).
Voilà pour un aperçu de ce à quoi les «précisions» ressemblent, à différentes technologies de synchronisation / interfaces. Quel niveau de précision vous convient, cela dépend de votre application, de vos besoins réels.