Comment Precision Time Protocol est déployé chez Meta

La mise en œuvre du Precision Time Protocol (PTP) chez Meta nous permet de synchroniser les systèmes qui pilotent nos produits et services jusqu'à une précision de l'ordre de la nanoseconde. Le prédécesseur de PTP, Network Time Protocol (NTP), nous a fourni une précision à la milliseconde, mais à mesure que nous évoluons vers des systèmes plus avancés sur la voie de la construction de la prochaine plate-forme informatique, le métaverse et l'IA, nous devons nous assurer que nos serveurs gardent le temps comme exactement et précisément que possible. Avec PTP en place, nous serons en mesure d'améliorer les technologies et les programmes de Meta - des communications et de la productivité au divertissement, à la confidentialité et à la sécurité - pour tout le monde, à travers les fuseaux horaires et dans le monde entier.

Le voyage vers PTP a duré des années, car nous avons dû repenser le fonctionnement du matériel et des logiciels de chronométrage au sein de nos serveurs et centres de données.

Nous partageons une plongée technique approfondie dans notre migration PTP et nos innovations qui l'ont rendue possible

Avant de plonger dans l'architecture PTP, explorons un cas d'utilisation simple pour une synchronisation extrêmement précise, à titre d'illustration.

Imaginez une situation dans laquelle un client écrit des données et essaie immédiatement de les lire. Dans les grands systèmes distribués, il y a de fortes chances que l'écriture et la lecture atterrissent sur des nœuds principaux différents.

Si la lecture touche un réplica distant qui ne dispose pas encore de la dernière mise à jour, il est possible que l'utilisateur ne voie pas sa propre écriture :

C'est pour le moins ennuyeux, mais le plus important est que cela viole une garantie de linéarisation qui permet une interaction avec un système distribué de la même manière qu'avec un serveur unique.

La manière typique de résoudre ce problème consiste à émettre plusieurs lectures sur différentes répliques et à attendre une décision de quorum. Cela consomme non seulement des ressources supplémentaires, mais retarde également considérablement la lecture en raison du long délai aller-retour du réseau.

L'ajout d'horodatages précis et fiables sur un serveur principal et des répliques nous permet simplement d'attendre que la réplique rattrape l'horodatage de lecture :

Cela accélère non seulement la lecture, mais économise également des tonnes de puissance de calcul.

Une condition très importante pour que cette conception fonctionne est que toutes les horloges soient synchronisées ou que le décalage entre une horloge et la source de temps soit connu. Le décalage, cependant, change en raison d'une correction constante, d'une dérive ou de simples variations de température. À cette fin, nous utilisons la notion de fenêtre d'incertitude (WOU), où nous pouvons dire avec une forte probabilité où se trouve le décalage. Dans cet exemple particulier, la lecture doit être bloquée jusqu'à l'horodatage de lecture plus WOU.

On pourrait dire que nous n'avons pas vraiment besoin de PTP pour cela. NTP fera très bien l'affaire. Eh bien, nous l'avons pensé aussi. Mais les expériences que nous avons menées en comparant notre implémentation NTP de pointe et une première version de PTP ont montré une différence de performances d'environ 100 fois :

Il existe plusieurs cas d'utilisation supplémentaires, notamment le suivi des événements, l'invalidation du cache, les améliorations de la détection des violations de la vie privée, la compensation de la latence dans le métaverse et l'exécution simultanée dans l'IA, dont beaucoup réduiront considérablement les besoins en capacité matérielle. Cela nous occupera pendant des années.

Maintenant que nous sommes sur la même page, voyons comment nous avons déployé PTP à l'échelle Meta.

Après plusieurs revues de fiabilité et de fonctionnement, nous avons abouti à une conception qui peut être divisée en trois composants principaux : le rack PTP, le réseau et le client.

Bouclez votre ceinture - nous allons plonger profondément.

Cela abrite le matériel et les logiciels qui servent le temps aux clients; le rack se compose de plusieurs composants critiques, dont chacun a été soigneusement sélectionné et testé.

L'antenne GNSS est facilement l'un des composants les moins appréciés. Mais c'est l'endroit où le temps prend naissance, du moins sur Terre.

Nous visons une précision à la nanoseconde. Et si le récepteur GNSS ne peut pas déterminer avec précision la position, il ne pourra pas calculer le temps. Nous devons fortement considérer le rapport signal sur bruit (SNR). Une antenne de mauvaise qualité ou un obstacle au ciel ouvert peut entraîner une erreur d'écart type de localisation 3D élevée. Pour que le temps soit déterminé de manière extrêmement précise, les récepteurs GNSS doivent entrer dans un mode dit de temps, qui nécessite généralement une erreur 3D <10 m.

Il est absolument essentiel d'assurer un ciel ouvert et d'installer une antenne stationnaire solide. Nous profitons également de belles vues :

Alors que nous testions différentes solutions d'antennes, une technologie GNSS sur fibre relativement nouvelle a attiré notre attention. Il est exempt de presque tous les inconvénients - il ne conduit pas l'électricité car il est alimenté par un laser via une fibre optique et le signal peut parcourir plusieurs kilomètres sans amplificateur.

À l'intérieur du bâtiment, il peut utiliser des panneaux de brassage fibre structurée et LC préexistants, ce qui simplifie considérablement la distribution du signal. De plus, les retards de signal pour la fibre optique sont bien définis à environ 4,9 ns par mètre. La seule chose qui reste est le retard introduit par la modulation directe RF vers laser et les séparateurs optiques, qui sont d'environ 45ns par boîte.

En réalisant des tests, nous avons confirmé que le délai d'antenne de bout en bout est déterministe (typiquement de l'ordre de quelques centaines de nanosecondes) et peut facilement être compensé côté Time Appliance.

Le Time Appliance est le cœur de l'infrastructure de synchronisation. C'est là que le temps prend son origine du point de vue de l'infrastructure du centre de données. En 2021, nous avons publié un article expliquant pourquoi nous avons développé un nouveau Time Appliance et pourquoi les solutions existantes ne suffiraient pas.

Mais c'était surtout dans le contexte du NTP. PTP, d'autre part, apporte des exigences encore plus élevées et des contraintes plus strictes. Plus important encore, nous nous sommes engagés à prendre en charge de manière fiable jusqu'à 1 million de clients par appareil sans nuire à l'exactitude et à la précision. Pour y parvenir, nous avons jeté un regard critique sur de nombreux composants traditionnels de Time Appliance et avons beaucoup réfléchi à leur fiabilité et à leur diversité.

Pour protéger notre infrastructure d'un bogue critique ou d'une attaque malveillante, nous avons décidé de commencer la diversification à partir de la source du temps — la Time Card. La dernière fois, nous avons beaucoup parlé de la conception de la carte de pointage et des avantages d'une solution basée sur FPGA. Dans le cadre de l'Open Compute Project (OCP), nous collaborons avec des fournisseurs tels qu'Orolia, Meinberg, Nvidia, Intel, Broadcom et ADVA, qui mettent tous en œuvre leurs propres cartes de temps, correspondant à la spécification OCP.

La carte de pointage est un composant essentiel qui nécessite une configuration et une surveillance spéciales. À cette fin, nous avons travaillé avec Orolia pour développer un logiciel disciplinaire, appelé oscillatord, pour différentes saveurs des Time Cards. C'est devenu l'outil par défaut pour :

En effet, les données exportées depuis oscillatord nous permettent de décider si le Time Appliance doit prendre du trafic ou doit être drainé.

Notre objectif ultime est de faire en sorte que des protocoles tels que PTP se propagent sur le réseau de paquets. Et si la Time Card est le cœur battant du Time Appliance, la carte réseau en est le visage. Chaque paquet PTP sensible au facteur temps est horodaté par la carte réseau. Cela signifie que l'horloge matérielle PTP (PHC) de la carte réseau doit être rigoureusement disciplinée.

Si nous copions simplement les valeurs d'horloge de la carte de pointage vers la carte réseau, à l'aide de phc2sys ou d'un outil similaire, la précision ne sera pas suffisante. En fait, nos expériences montrent que nous perdrions facilement ~ 1 à 2 microsecondes en passant par PCIe, CPU, NUMA, etc. Les performances de synchronisation sur le bus PCIe s'amélioreront considérablement avec la technologie émergente de mesure du temps de précision (PTM), car le le développement et la prise en charge de divers périphériques dotés de cette capacité sont en cours.

Pour notre application, puisque nous utilisons des cartes réseau avec des capacités PPS-in, nous avons utilisé ts2phc, qui copie d'abord les valeurs d'horloge, puis aligne les fronts d'horloge en fonction d'un signal d'impulsion par seconde (PPS). Cela nécessite un câble supplémentaire entre la sortie PPS de la carte de pointage et l'entrée PPS de la carte réseau, comme indiqué dans l'image ci-dessous.

Nous surveillons constamment le décalage et veillons à ce qu'il ne sorte jamais d'une fenêtre de ± 50 ns entre la carte de pointage et la carte réseau :

Nous surveillons également l'interface de sortie PPS de la carte réseau pour agir comme une sécurité intégrée et nous assurer que nous savons réellement ce qui se passe avec le PHC sur la carte réseau.

Lors de l'évaluation de différentes implémentations de serveurs PTP préexistantes, nous avons rencontré des problèmes d'évolutivité avec les solutions open source et propriétaires fermées, y compris les serveurs PTP accélérés par FPGA que nous avons évalués. Au mieux, nous pourrions obtenir environ 50 000 clients par serveur. À notre échelle, cela signifie que nous devrions déployer de nombreux racks remplis de ces appareils.

Étant donné que la sauce secrète de PTP est l'utilisation d'horodatages matériels, l'implémentation du serveur n'a pas besoin d'être un programme C hautement optimisé ou même une appliance accélérée par FPGA.

Nous avons implémenté un serveur PTP unicast PTPv2 évolutif dans Go, que nous avons nommé ptp4u, et l'avons ouvert sur GitHub. Avec quelques optimisations mineures, nous avons pu prendre en charge plus d'un million de clients simultanés par appareil, ce qui a été vérifié de manière indépendante par un appareil certifié IEEE 1588v2.

Cela a été possible grâce à l'utilisation simple mais élégante de canaux dans Go qui nous a permis de faire circuler les abonnements entre plusieurs travailleurs puissants.

Étant donné que ptp4u s'exécute en tant que processus sur une machine Linux, nous bénéficions automatiquement et gratuitement de tous les avantages, tels que la prise en charge d'IPv6, le pare-feu, etc.

Le serveur ptp4u dispose de nombreuses options de configuration, lui permettant de passer des paramètres changeant dynamiquement tels quePrécision de l'horloge PTP,Classe d'horloge PTP,et unDécalage UTC– qui est actuellement fixé à 37 secondes (nous espérons que cela deviendra une constante) – jusqu'aux clients.

Afin de générer fréquemment ces paramètres, nous avons implémenté un service séparé appelé c4u, qui surveille en permanence plusieurs sources d'informations et compile la configuration active pour ptp4u :

Cela nous donne de la flexibilité et de la réactivité si l'environnement change. Par exemple, si nous perdons le signal GNSS sur l'un des Time Appliances, nous basculerons la ClockClass sur HOLDOVER et les clients s'en éloigneront immédiatement. Il calcule également ClockAccuracy à partir de nombreuses sources différentes, telles que la qualité de synchronisation ts2phc, l'état de l'horloge atomique, etc.

Nous calculons la valeur de décalage UTC en fonction du contenu du package tzdata car nous transmettons le temps atomique international (TAI) aux clients.

Nous voulions nous assurer que nos Time Appliances sont constamment et indépendamment évaluées par un dispositif de surveillance certifié bien établi. Heureusement, nous avons déjà fait beaucoup de progrès dans l'espace NTP avec Calnex, et nous étions en mesure d'appliquer une approche similaire à PTP.

Nous avons collaboré avec Calnex pour prendre leur appareil de terrain et le réutiliser pour une utilisation dans un centre de données, ce qui impliquait de modifier le facteur de forme physique et d'ajouter la prise en charge de fonctionnalités telles que IPv6.

Nous connectons la sortie Time Appliance NIC PPS au Calnex Sentinel, ce qui nous permet de surveiller le PHC du NIC avec une précision de l'ordre de la nanoseconde.

Nous explorerons la surveillance en détail dans "Comment nous surveillons l'architecture PTP", ci-dessous.

Le protocole PTP prend en charge l'utilisation des modes monodiffusion et multidiffusion pour la transmission des messages PTP. Pour les déploiements de grands centres de données, la monodiffusion est préférée à la multidiffusion car elle simplifie considérablement la conception du réseau et les exigences logicielles.

Examinons un flux de monodiffusion PTP typique :

Un client démarre la négociation (demande de transmission unicast). Il doit donc envoyer :

Schématiquement (juste pour l'illustration), cela ressemblera à ceci :

Nous avons d'abord envisagé de tirer parti des horloges limites dans notre conception. Cependant, les horloges limites présentent plusieurs inconvénients et complications :

Pour éviter cette complexité supplémentaire, nous avons décidé de nous fier uniquement aux horloges transparentes PTP.

Les horloges transparentes (TC) permettent aux clients de tenir compte des variations de latence du réseau, garantissant une estimation beaucoup plus précise du décalage d'horloge. Chaque commutateur de centre de données dans le chemin entre le client et le serveur de temps rapporte le temps que chaque paquet PTP passe à transiter par le commutateur en mettant à jour un champ dans la charge utile du paquet, le bien nommé Correction Field (CF).

Les clients PTP (également appelés horloges ordinaires ou OC) calculent le délai de chemin moyen du réseau et les décalages d'horloge vers les serveurs de temps (horloges grand maître ou GM) à l'aide de quatre horodatages (T1, T2, T3 et T4) et de deux valeurs de champ de correction (CFa et CFb), comme indiqué dans le schéma ci-dessous :

Pour comprendre l'impact d'une seule horloge transparente désactivée sur le chemin entre le client et un serveur, nous pouvons examiner les journaux :

Nous pouvons voir le retard de chemin exploser, parfois même devenir négatif, ce qui ne devrait pas se produire lors d'opérations normales. Cela a un impact considérable sur le décalage, le faisant passer de ± 100 nanosecondes à -400 microsecondes (plus de 4000 fois la différence). Et le pire de tout, ce décalage ne sera même pas précis, car les calculs de retard de trajet moyen sont incorrects.

Selon nos expériences, les commutateurs modernes dotés de grands tampons peuvent retarder les paquets jusqu'à quelques millisecondes, ce qui entraînera des centaines de microsecondes d'erreur de calcul du délai de chemin. Cela entraînera les pics de décalage et sera clairement visible sur les graphiques :

L'essentiel est que l'exécution de PTP dans des centres de données en l'absence de TC entraîne une asymétrie imprévisible et inexplicable dans le temps d'aller-retour. Et le pire de tout - il n'y aura pas de moyen simple de détecter cela. 500 microsecondes peuvent ne pas sembler beaucoup, mais lorsque les clients s'attendent à ce qu'un WOU dure plusieurs microsecondes, cela peut entraîner une violation du SLA.

L'horodatage du paquet entrant est une fonctionnalité relativement ancienne prise en charge par le noyau Linux depuis des décennies. Par exemple, les horodatages logiciels (noyau) sont utilisés par les démons NTP depuis des années. Il est important de comprendre que les horodatages ne sont pas inclus par défaut dans la charge utile du paquet et, si nécessaire, doivent y être placés par l'application utilisateur.

La lecture de l'horodatage RX depuis l'espace utilisateur est une opération relativement simple. Lorsque le paquet arrive, la carte réseau (ou un noyau) horodatera cet événement et inclura l'horodatage dans le message de contrôle du socket, ce qui est facile à comprendre avec le paquet lui-même en appelant un appel système recvmsg avec l'indicateur MSG_ERRQUEUE défini.

Pour l'horodatage TX Hardware, c'est un peu plus compliqué. Lorsque sendto syscall est exécuté, cela ne conduit pas à un départ de paquet immédiat ni à une génération d'horodatage TX. Dans ce cas, l'utilisateur doit interroger le socket jusqu'à ce que l'horodatage soit correctement placé par le noyau. Il faut souvent attendre plusieurs millisecondes ce qui limite naturellement le débit d'envoi.

Les horodatages matériels sont la sauce secrète qui rend PTP si précis. La plupart des cartes réseau modernes prennent déjà en charge les horodatages matériels où le pilote de la carte réseau remplit la section correspondante.

Il est très facile de vérifier le support en exécutant la commande ethtool :

Il est toujours possible d'utiliser PTP avec des horodatages logiciels (noyau), mais il n'y aura aucune garantie solide sur leur qualité, leur précision et leur exactitude.

Nous avons également évalué cette possibilité et avons même envisagé d'implémenter un changement dans le noyau pour "simuler" les horodatages matériels avec un logiciel où les horodatages matériels ne sont pas disponibles. Cependant, sur un hôte très occupé, nous avons observé que la précision des horodatages logiciels sautait à des centaines de microsecondes et nous avons dû abandonner cette idée.

ptp4l est un logiciel open source capable d'agir à la fois comme client PTP et comme serveur PTP. Alors que nous devions implémenter notre propre solution de serveur PTP pour des raisons de performances, nous avons décidé de nous en tenir à ptp4l pour le cas d'utilisation client.

Les premiers tests en laboratoire ont révélé que ptp4l peut fournir une excellente qualité de synchronisation prête à l'emploi et aligner le temps sur les PHC du réseau local jusqu'à des dizaines de nanosecondes.

Cependant, lorsque nous avons commencé à étendre notre configuration, certains problèmes ont commencé à survenir.

Dans un exemple particulier, nous avons commencé à remarquer des "pics" occasionnels dans le décalage. Après une analyse approfondie, nous avons identifié les limitations matérielles fondamentales de l'une des cartes réseau les plus populaires du marché :

Cela a finalement conduit au remplacement des horodatages légitimes par des horodatages provenant d'autres paquets. Mais ce qui a encore aggravé les choses, c'est que le pilote de la carte réseau a essayé d'être trop intelligent et a placé les horodatages logiciels dans la section d'horodatage matériel du message de contrôle du socket sans le dire à personne.

Il s'agit d'une limitation matérielle fondamentale qui affecte une grande partie de la flotte et qui est impossible à résoudre.

Nous avons dû implémenter un filtre de décalage des valeurs aberrantes, ce qui a modifié le comportement du servo PI et l'a rendu avec état. Cela a entraîné le rejet occasionnel de valeurs aberrantes et la définition de la fréquence moyenne pendant le micro-holdover :

Sans ce filtre, ptp4l aurait piloté la fréquence PHC très haut, ce qui entraînerait plusieurs secondes d'oscillation et une mauvaise qualité dans la fenêtre d'incertitude que nous en générons.

Un autre problème est né de la conception de BMCA. Le but de cet algorithme est de sélectionner le meilleur Time Appliance lorsqu'il y en a plusieurs à choisir dans le ptp4l.conf. Il le fait en comparant plusieurs attributs fournis par les serveurs de temps dans les messages d'annonce :

Le problème se manifeste lorsque tous les attributs susmentionnés sont identiques. BMCA utilise l'adresse MAC de Time Appliance comme condition de départage, ce qui signifie que dans des conditions de fonctionnement normales, un serveur de temps attirera tout le trafic client.

Pour lutter contre cela, nous avons introduit ce que l'on appelle un "sharding" avec différents clients PTP attribués à différents sous-groupes d'appareils temporels de l'ensemble du pool.

Cela ne résolvait que partiellement le problème avec un serveur dans chaque sous-groupe prenant toute la charge pour ce groupe. La solution était de permettre aux clients d'exprimer une préférence, et nous avons donc introduit Priority3 dans les critères de sélection juste au-dessus de l'adresse MAC tiebreaker. Cela signifie que les clients configurés pour utiliser les mêmes Time Appliances peuvent préférer des serveurs différents.

Client 1 :

[unicast_master_table]

UDPv6 time_server1 1

UDPv6 time_server2 2

UDPv6 time_server3 3

Client 2 :

[unicast_master_table]

UDPv6 time_server2 1

UDPv6 time_server3 2

UDPv6 time_server1 3

Cela garantit que nous pouvons répartir la charge uniformément sur tous les Time Appliances dans des conditions de fonctionnement normales.

Un autre défi majeur auquel nous avons été confrontés était de nous assurer que PTP fonctionnait avec des cartes réseau multi-hôtes - plusieurs hôtes partageant la même interface réseau physique et donc un seul PHC. Cependant, ptp4l n'en a aucune connaissance et essaie de discipliner le PHC comme s'il n'y avait pas d'autres voisins.

Certains fabricants de cartes réseau ont développé un mode dit « d'exécution libre » où ptp4l ne fait que discipliner la formule à l'intérieur du pilote du noyau. Le PHC réel n'est pas affecté et continue de fonctionner librement. Ce mode se traduit par une précision légèrement inférieure, mais il est complètement transparent pour ptp4l.

Les autres fabricants de cartes réseau ne prennent en charge qu'un mode "horloge en temps réel", lorsque le premier hôte à saisir le verrou discipline réellement le PHC. L'avantage ici est un étalonnage plus précis et une conservation de meilleure qualité, mais cela entraîne un problème distinct avec ptp4l exécuté sur les autres hôtes utilisant la même carte réseau, car les tentatives de réglage de la fréquence PHC n'ont aucun impact, ce qui entraîne des décalages d'horloge et des calculs de fréquence inexacts.

Pour décrire la configuration du centre de données, nous avons développé et publié un profil PTP, qui reflète les cas extrêmes susmentionnés et bien d'autres.

Nous évaluons la possibilité d'utiliser un autre client PTP. Nos principaux critères sont :

Nous évaluons le client Timebeat PTP et, jusqu'à présent, il semble très prometteur.

Dans le protocole PTP, peu importe l'heure de propagation tant que nous transmettons un décalage UTC aux clients. Dans notre cas, il s'agit du temps atomique international (TAI), mais certaines personnes peuvent choisir UTC. Nous aimons considérer le temps que nous fournissons comme un compteur qui s'incrémente en continu.

À ce stade, nous ne disciplinons pas l'horloge système et ptp4l est uniquement utilisé pour discipliner le PHC de la carte réseau.

Synchroniser les PHC sur la flotte de serveurs est une bonne chose, mais cela ne présente aucun avantage à moins qu'il existe un moyen de lire et de manipuler ces chiffres sur le client.

À cette fin, nous avons développé une API simple et légère appelée fbclock qui rassemble les informations de PHC et ptp4l et expose des informations faciles à digérer sur la fenêtre d'incertitude :

Grâce à un ioctl PTP_SYS_OFFSET_EXTENDED très efficace, fbclock obtient un horodatage actuel du PHC, les dernières données de ptp4l, puis applique une formule mathématique pour calculer la fenêtre d'incertitude (WOU):

Comme vous pouvez le voir, l'API ne renvoie pas l'heure actuelle (alias time.Now()). Au lieu de cela, il renvoie une fenêtre de temps qui contient l'heure réelle avec un degré de probabilité très élevé. Dans cet exemple particulier, nous savons que notre fenêtre d'incertitude est de 694 nanosecondes et que le temps est compris entre (TAI) jeudi 02 juin 2022 17h44 : 08:711023134 et jeudi 02 juin 2022 17:44:08:711023828.

Cette approche permet aux clients d'attendre que l'intervalle soit écoulé pour garantir l'ordre exact des transactions.

Mesurer la précision du temps ou (Window Of Uncertainty) signifie qu'à côté de la valeur de temps fournie, une fenêtre (une valeur plus/moins) est présentée qui est garantie d'inclure le temps réel avec un niveau de certitude élevé.

Le degré de certitude dont nous avons besoin est déterminé par l'importance que l'heure soit correcte et cela dépend de l'application spécifique.

Dans notre cas, cette certitude doit être meilleure que 99,9999% (6-9s). À ce niveau de fiabilité, vous pouvez vous attendre à moins d'une erreur sur 1 000 000 de mesures.

L'estimation du taux d'erreur utilise l'observation de l'historique des données (histogramme) pour ajuster une fonction de distribution de probabilité (PDF). À partir de la fonction de distribution de probabilité, on peut calculer la variance (prendre une racine carrée et obtenir l'écart type) et à partir de là, ce sera une simple multiplication pour arriver à l'estimation de la distribution en fonction de sa valeur.

Vous trouverez ci-dessous un histogramme tiré de la mesure de décalage de ptp4l fonctionnant sur l'horloge ordinaire.

Pour estimer la variance totale (E2E), il est nécessaire de connaître la variance de l'erreur de temps accumulée par le serveur de temps jusqu'au nœud final NIC. Cela inclut le GNSS, l'horloge atomique et la carte de pointage PHC vers NIC PHC (ts2phc). Le fabricant fournit la variance d'erreur GNSS. Dans le cas de l'UBX-F9T, il est d'environ 12 nanosecondes. Pour l'horloge atomique, la valeur dépend du seuil de discipline que nous avons défini. Plus le seuil de discipline est strict, plus la variance de décalage est faible, mais les performances de maintien sont plus faibles. Au moment de l'exécution de cette expérience, la variance d'erreur de l'horloge atomique a été mesurée à 43ns (écart type, std). Enfin, l'outil ts2phc augmente la variance de 30ns (std) résultant en une variance totale de 52ns.

Les résultats observés correspondent à la variance calculée obtenue par la "Sum of Variance Law".

Selon la loi de la somme des variances, il suffit d'additionner toute la variance. Dans notre cas, nous savons que l'erreur totale E2E de l'observateur (mesurée via le Calnex Sentinel) est d'environ 92ns.

D'autre part pour notre estimation, nous pouvons avoir ce qui suit :

Variance E2E estimée = [Variance GNSS + Variance MAC + Variance ts2phc] + [Variance de décalage PTP4L] = [Variance du serveur horaire] + [Variance de l'horloge ordinaire]

Brancher les valeurs :

Variance E2E estimée = (12ns 2) + (43ns2) + (52ns2) + (61ns2) = 8418, ce qui correspond à 91,7ns

Ces résultats montrent qu'en propageant la variance d'erreur vers le bas de l'arbre d'horloge, la variance d'erreur E2E peut être estimée avec une bonne précision. La variance d'erreur E2E peut être utilisée pour calculer la fenêtre d'incertitude (WOU) sur la base du tableau suivant.

Simplement, en multipliant la variance d'erreur E2E estimée par 4,745, nous pouvons estimer la fenêtre d'incertitude pour la probabilité de 6-9s.

Pour notre système donné, la probabilité de 6-9s est d'environ 92ns x 4,745 = 436ns

Cela signifie qu'étant donné un temps rapporté par PTP, compte tenu d'une taille de fenêtre de 436ns autour de la valeur garantit d'inclure le temps réel avec une confiance de plus de 99,9999 %.

Bien que tout ce qui précède semble logique et génial, il y a là une grande hypothèse. L'hypothèse est que la connexion au serveur de temps ouvert (OTS) est disponible et que tout est en mode de fonctionnement normal. Beaucoup de choses peuvent mal tourner, comme l'OTS qui tombe en panne, le commutateur qui tombe en panne, les messages de synchronisation qui ne se comportent pas comme ils sont censés le faire, quelque chose entre les deux décide de réveiller les astreintes, etc. Dans une telle situation, le calcul lié à l'erreur devrait entrer en mode d'arrêt. Les mêmes choses s'appliquent à l'OTS lorsque le GNSS est en panne. Dans une telle situation, le système augmentera la fenêtre d'incertitude en fonction d'un taux composé. Le taux sera estimé en fonction de la stabilité de l'oscillateur (variance de défilement) pendant les opérations normales. Sur l'OTS, le taux composé est ajusté par la surveillance télémétrique précise du système (température, vibrations, etc.). Il y a beaucoup de travail en termes de calibrage des coefficients ici et d'obtention du meilleur résultat et nous travaillons toujours sur ces ajustements.

Pendant les périodes de disponibilité de la synchronisation du réseau, le servo ajuste constamment la fréquence de l'horloge locale côté client (en supposant que le pas initial a entraîné la convergence). Une interruption de la synchronisation du réseau (perte de connexion au serveur de temps ou arrêt du serveur de temps lui-même) laissera le servo avec une dernière valeur de correction de fréquence. Par conséquent, une telle valeur n'est pas destinée à être une estimation de la précision de l'horloge locale mais plutôt un ajustement de fréquence temporaire pour réduire l'erreur de temps (décalage) mesurée entre le cline et le serveur de temps.

Par conséquent, il est d'abord nécessaire de tenir compte des périodes de perte de synchronisation et d'utiliser la meilleure estimation de la correction de fréquence (généralement, la moyenne de défilement des valeurs de correction précédentes) et ensuite, de tenir compte de l'augmentation de la limite d'erreur en examinant la dernière valeur de correction et en la comparant. avec la moyenne défilante des valeurs de correction précédentes.

La surveillance est l'une des parties les plus importantes de l'architecture PTP. En raison de la nature et de l'impact du service, nous avons passé pas mal de temps à travailler sur l'outillage.

Nous avons travaillé avec l'équipe Calnex pour créer l'API Sentinel HTTP, qui nous permet de gérer, configurer et exporter des données depuis l'appareil. Chez Meta, nous avons créé et open source un outil de ligne de commande API permettant des interactions humaines et conviviales avec les scripts.

En utilisant Calnex Sentinel 2.0, nous sommes en mesure de surveiller trois métriques principales par appareil temporel - NTP, PTP et PPS.

Cela nous permet d'informer les ingénieurs de tout problème avec les appareils et de détecter précisément où se situe le problème.

Par exemple, dans ce cas, les stations de surveillance PTP et PPS présentent une variation d'environ moins de 100 nanosecondes sur 24 heures lorsque NTP reste dans les 8 microsecondes.

Afin de surveiller notre configuration, nous avons implémenté et ouvert un outil appelé ptpcheck. Il a de nombreuses sous-commandes différentes, mais les plus intéressantes sont les suivantes :

La sous-commande client fournit un état général d'un client ptp. Il signale l'heure de réception du dernier message de synchronisation, le décalage d'horloge par rapport au serveur de temps sélectionné, le délai moyen du chemin et d'autres informations utiles :

Sous-commande client qui permet d'interroger une API fbclock et d'obtenir une fenêtre d'incertitude actuelle :

La surveillance du client de style Chrony permet de voir tous les serveurs de temps configurés dans le fichier de configuration du client, leur statut et la qualité du temps.

La sous-commande du serveur permet de lire un résumé de la carte de pointage.

Par exemple, nous pouvons voir que la dernière correction sur la Time Card n'était que de 1 nanoseconde.

Cette sous-commande nous permet d'obtenir une différence entre deux PHC :

Dans ce cas particulier, la différence entre Time Card et une carte réseau sur un serveur est de -15 nanosecondes.

C'est bien de déclencher une surveillance périodiquement ou à la demande, mais on veut aller encore plus loin. Nous voulons savoir ce que le client vit réellement. À cette fin, nous avons intégré plusieurs compartiments directement à l'intérieur de l'API fbclock basés sur des compteurs atomiques, qui s'incrémentent à chaque fois que le client fait un appel à une API :

Cela nous permet de voir clairement quand le client rencontre un problème - et souvent avant même que le client ne le remarque.

Le protocole PTP (et ptp4l en particulier) n'a pas de processus de sélection de quorum (contrairement à NTP et chrony). Cela signifie que le client sélectionne et fait confiance au serveur de temps en fonction des informations fournies via les messages d'annonce. Cela est vrai même si le serveur de temps lui-même est erroné.

Pour de telles situations, nous avons mis en place une dernière ligne de défense appelée contrôle de linéarisabilité.

Imaginez une situation dans laquelle un client est configuré pour utiliser trois serveurs de temps et le client est abonné à un serveur de temps défectueux (par exemple, le serveur de temps 2) :

Dans cette situation, le client PTP pensera que tout va bien, mais les informations qu'il fournit à l'application consommant du temps seront incorrectes, car la fenêtre d'incertitude sera décalée et donc imprécise.

Pour lutter contre cela, en parallèle, le fbclock établit une communication avec les serveurs de temps restants et compare les résultats. Si la majorité des décalages sont élevés, cela signifie que le serveur suivi par notre client est la valeur aberrante et que le client n'est pas linéarisable, même si la synchronisation entre le serveur de temps 2 et le client est parfaite.

Nous pensons que PTP deviendra la norme pour conserver l'heure dans les réseaux informatiques dans les décennies à venir. C'est pourquoi nous le déployons à une échelle sans précédent. Nous avons dû jeter un regard critique sur l'ensemble de notre pile d'infrastructure - de l'antenne GNSS à l'API client - et dans de nombreux cas, nous avons même reconstruit les choses à partir de zéro.

Alors que nous poursuivons notre déploiement de PTP, nous espérons que davantage de fournisseurs qui produisent des équipements de réseau profiteront de notre travail pour apporter de nouveaux équipements prenant en charge PTP à l'industrie. Nous avons ouvert la plupart de notre travail, de notre code source à notre matériel, et nous espérons que l'industrie se joindra à nous pour apporter PTP au monde. Tout cela a été fait au nom de l'amélioration des performances et de la fiabilité des solutions existantes, mais aussi dans l'optique d'ouvrir de nouveaux produits, services et solutions à l'avenir.

Nous tenons à remercier toutes les personnes impliquées dans cette entreprise, des équipes internes de Meta aux fournisseurs et fabricants qui collaborent avec nous. Un merci spécial à Andrei Lukovenko, qui a connecté les passionnés de temps.

Ce voyage n'est qu'à un pour cent terminé.