Pour autant que je sache, la précision de la synchronisation NTP dépend fortement du réseau. J'ai vu des nombres de 50 microsecondes à "moins d'une seconde" sur Internet. Eh bien, c'est une énorme différence.
Je crois que la dépendance à la précision est une grande question à étudier, mais jusqu'à présent, je n'ai trouvé aucun matériau, qui indique clairement que, disons, une configuration particulière accorde cette précision particulière.
Il est dit sur http://www.ntp.org/ntpfaq/NTP-s-algo.htm :
Une différence de temps inférieure à 128 ms entre le serveur et le client est requise pour maintenir la synchronisation NTP. La précision typique sur Internet varie d'environ 5 ms à 100 ms, pouvant varier avec les retards du réseau. Une enquête récente [2] suggère que 90% des serveurs NTP ont des retards de réseau inférieurs à 100 ms, et environ 99% sont synchronisés en une seconde avec le pair de synchronisation.
Avec la synchronisation PPS, une précision de 50 µs et une stabilité inférieure à 0,1 PPM sont réalisables sur un PC Pentium (sous Linux par exemple).
C'est quelque chose, mais peut-être qu'il y a une analyse plus approfondie sur le sujet?
Réponses:
Personne ne peut garantir le bon fonctionnement de NTP sur votre réseau, car personne ne sait à quel point votre réseau est bien connecté à Internet et aux serveurs d'horloge qui s'y trouvent. Cependant, selon la page de l'algorithme de discipline d'horloge sur ntp.org
Notez que la latence grande mais stable entre votre réseau local et les serveurs d'horloge d'Internet n'a pas un aussi mauvais effet sur la précision qu'une latence très variable.
Vous ne dites pas où vous avez obtenu les estimations ci-dessus ('50 microsecondes à ... "en dessous d'une seconde" '), donc je ne peux pas les commenter, mais d'après mon expérience, 50us est peu probable à moins que vous n'ayez un lien direct source d'horloge, et 1 est peu probable, sauf si vous avez un morceau de chaîne humide vous connectant à Internet et que vous utilisez des serveurs en amont en Antarctique.
Edit : le texte que vous citez maintenant dans votre question donne un pointeur vers un article qui, en 1999, a en effet établi que 99% des serveurs ntp sont synchronisés en une seconde. Heureusement, il y a des travaux plus récents; dans cet article, certains auteurs de l'Université fédérale de Parana, au Brésil, ont répété l'expérience en 2005 et ont constaté (si je comprends bien leur Fig. 1) qu'au nord de 99% - plus comme 99,5% - des serveurs ont maintenant des décalages inférieurs à 100 ms, et que 90% ont des décalages inférieurs à 10 ms. Cela correspond assez bien à mes expériences (voir ci-dessus).
Edit 2 : une dernière ride: toutes ces études ne recherchent pas la précision de l'horloge locale, mais à quel point elle diffère de l'horloge de référence en amont. Ce n'est manifestement pas la même chose. Mais le premier est inconnaissable; pour savoir à quel point votre horloge est erronée, vous devez savoir exactement quelle heure il est, et si vous le saviez, pourquoi auriez-vous mal réglé votre horloge en premier lieu? Sachez simplement que ce que ces études mesurent n'est pas la différence entre l'horloge locale et l'heure absolue, mais entre l'horloge locale et l'horloge de référence.
la source
Quel problème essayez-vous de résoudre?
La solution que j'ai rencontrée pour les environnements nécessitant plus de précision que NTP est le Precision Time Protocol (PTP) . Je l'ai eu dans les applications de calcul scientifique et de calcul financier. Il y a cependant des compromis .
Voir aussi: synchronisation horaire ptp sur centos6 / rhel
la source
Quelques autres choses méritent d'être mentionnées:
la source
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.
la source