Wie das Precision Time Protocol bei Meta eingesetzt wird

Durch die Implementierung des Precision Time Protocol (PTP) bei Meta können wir die Systeme, die unsere Produkte und Dienstleistungen steuern, auf Nanosekundengenauigkeit synchronisieren. Der Vorgänger von PTP, das Network Time Protocol (NTP), lieferte uns eine Präzision im Millisekundenbereich, aber während wir auf dem Weg zum Aufbau der nächsten Computerplattform, dem Metaversum und der KI, auf fortschrittlichere Systeme umsteigen, müssen wir sicherstellen, dass unsere Server die Zeit einhalten genau und präzise wie möglich. Mit PTP können wir die Technologien und Programme von Meta verbessern – von Kommunikation und Produktivität bis hin zu Unterhaltung, Datenschutz und Sicherheit – für alle, über Zeitzonen hinweg und auf der ganzen Welt.

Der Weg zu PTP hat Jahre gedauert, da wir überdenken mussten, wie sowohl die Hardware als auch die Software für die Zeitmessung in unseren Servern und Rechenzentren funktionieren.

Wir geben einen tiefen technischen Einblick in unsere PTP-Migration und unsere Innovationen, die sie möglich gemacht haben

Bevor wir uns mit der PTP-Architektur befassen, wollen wir zur Veranschaulichung einen einfachen Anwendungsfall für äußerst genaues Timing untersuchen.

Stellen Sie sich eine Situation vor, in der ein Client Daten schreibt und sofort versucht, sie zu lesen. In großen verteilten Systemen ist die Wahrscheinlichkeit hoch, dass Schreib- und Lesevorgänge auf unterschiedlichen Back-End-Knoten landen.

Wenn der Lesevorgang ein Remote-Replikat betrifft, das noch nicht über das neueste Update verfügt, besteht die Möglichkeit, dass der Benutzer seinen eigenen Schreibvorgang nicht sieht:

Das ist zumindest ärgerlich, aber noch wichtiger ist, dass dadurch eine Linearisierbarkeitsgarantie verletzt wird, die die Interaktion mit einem verteilten System auf die gleiche Weise wie mit einem einzelnen Server ermöglicht.

Der typische Weg, dieses Problem zu lösen, besteht darin, mehrere Lesevorgänge an verschiedene Replikate durchzuführen und auf eine Quorumsentscheidung zu warten. Dies verbraucht nicht nur zusätzliche Ressourcen, sondern verzögert auch den Lesevorgang aufgrund der langen Netzwerk-Roundtrip-Verzögerung erheblich.

Durch das Hinzufügen präziser und zuverlässiger Zeitstempel auf einem Back-End und Replikaten können wir einfach warten, bis das Replikat den Lesezeitstempel einholt:

Dies beschleunigt nicht nur das Lesen, sondern spart auch jede Menge Rechenleistung.

Eine sehr wichtige Voraussetzung dafür, dass dieses Design funktioniert, ist, dass alle Uhren synchron sind oder dass der Versatz zwischen einer Uhr und der Zeitquelle bekannt ist. Der Offset ändert sich jedoch aufgrund ständiger Korrektur, Drift oder einfacher Temperaturschwankungen. Zu diesem Zweck verwenden wir den Begriff eines Fensters der Unsicherheit (WOU), bei dem wir mit hoher Wahrscheinlichkeit sagen können, wo sich der Offset befindet. In diesem speziellen Beispiel sollte der Lesevorgang bis zum Lesezeitstempel plus WOU blockiert werden.

Man könnte argumentieren, dass wir dafür kein PTP brauchen. NTP reicht völlig aus. Naja, das dachten wir auch. Aber Experimente, die wir zum Vergleich unserer hochmodernen NTP-Implementierung und einer frühen Version von PTP durchgeführt haben, zeigten einen etwa 100-fachen Leistungsunterschied:

Es gibt mehrere zusätzliche Anwendungsfälle, darunter Ereignisverfolgung, Cache-Invalidierung, Verbesserungen bei der Erkennung von Datenschutzverletzungen, Latenzkompensation im Metaversum und gleichzeitige Ausführung in KI, von denen viele die Anforderungen an die Hardwarekapazität erheblich reduzieren. Das wird uns noch viele Jahre lang beschäftigen.

Da wir uns nun auf dem gleichen Stand befinden, sehen wir uns an, wie wir PTP im Meta-Maßstab bereitgestellt haben.

Nach mehreren Zuverlässigkeits- und Betriebsprüfungen sind wir zu einem Design gelangt, das in drei Hauptkomponenten unterteilt werden kann: das PTP-Rack, das Netzwerk und den Client.

Schnall dich an – wir stürzen uns in die Tiefe.

Hier ist die Hardware und Software untergebracht, die den Kunden zur Verfügung steht. Das Rack besteht aus mehreren kritischen Komponenten, die jeweils sorgfältig ausgewählt und getestet wurden.

Die GNSS-Antenne ist mit Sicherheit eine der am wenigsten geschätzten Komponenten. Aber hier entsteht zumindest auf der Erde die Zeit.

Wir streben eine Genauigkeit im Nanosekundenbereich an. Und wenn der GNSS-Empfänger die Position nicht genau bestimmen kann, ist er nicht in der Lage, die Zeit zu berechnen. Wir müssen das Signal-Rausch-Verhältnis (SNR) stark berücksichtigen. Eine minderwertige Antenne oder ein Hindernis im freien Himmel kann zu einem hohen Fehler der 3D-Standortstandardabweichung führen. Damit die Zeit äußerst genau bestimmt werden kann, sollten GNSS-Empfänger in einen sogenannten Zeitmodus wechseln, der typischerweise einen 3D-Fehler von <10 m erfordert.

Es ist unbedingt erforderlich, einen freien Himmel zu gewährleisten und eine solide stationäre Antenne zu installieren. Wir können auch einige schöne Ausblicke genießen:

Während wir verschiedene Antennenlösungen testeten, erregte eine relativ neue GNSS-über-Glasfaser-Technologie unsere Aufmerksamkeit. Es weist fast alle Nachteile auf: Es leitet keinen Strom, da es von einem Laser über eine Glasfaser gespeist wird, und das Signal kann ohne Verstärker mehrere Kilometer zurücklegen.

Im Gebäudeinneren können bereits vorhandene strukturierte Glasfaser- und LC-Patchpanels genutzt werden, was die Signalverteilung deutlich vereinfacht. Darüber hinaus sind die Signalverzögerungen für Glasfasern mit etwa 4,9 ns pro Meter gut definiert. Das Einzige, was übrig bleibt, ist die Verzögerung, die durch die direkte RF-Laser-Modulation und die optischen Splitter entsteht und etwa 45 ns pro Box beträgt.

Durch die Durchführung von Tests haben wir bestätigt, dass die Ende-zu-Ende-Antennenverzögerung deterministisch ist (typischerweise etwa einige hundert Nanosekunden) und auf Seiten der Time Appliance leicht kompensiert werden kann.

Die Time Appliance ist das Herzstück der Timing-Infrastruktur. Aus Sicht der Rechenzentrumsinfrastruktur entsteht hier die Zeit. Im Jahr 2021 haben wir einen Artikel veröffentlicht, in dem wir erklären, warum wir ein neues Time Appliance entwickelt haben und warum bestehende Lösungen nicht ausreichen.

Dies geschah jedoch hauptsächlich im Zusammenhang mit NTP. PTP hingegen bringt noch höhere Anforderungen und strengere Einschränkungen mit sich. Am wichtigsten ist, dass wir uns dazu verpflichtet haben, bis zu 1 Million Kunden pro Appliance zuverlässig zu unterstützen, ohne dabei die Genauigkeit und Präzision zu beeinträchtigen. Um dies zu erreichen, haben wir viele der traditionellen Komponenten des Time Appliance kritisch unter die Lupe genommen und intensiv über ihre Zuverlässigkeit und Vielfalt nachgedacht.

Um unsere Infrastruktur vor einem kritischen Fehler oder einem böswilligen Angriff zu schützen, haben wir beschlossen, mit der Diversifizierung von der Zeitquelle aus zu beginnen – der Time Card. Letztes Mal haben wir viel über das Time Card-Design und die Vorteile einer FPGA-basierten Lösung gesprochen. Im Rahmen des Open Compute Project (OCP) arbeiten wir mit Anbietern wie Orolia, Meinberg, Nvidia, Intel, Broadcom und ADVA zusammen, die alle ihre eigenen Zeitkarten implementieren, die der OCP-Spezifikation entsprechen.

Die Zeitkarte ist eine kritische Komponente, die eine spezielle Konfiguration und Überwachung erfordert. Zu diesem Zweck haben wir mit Orolia zusammengearbeitet, um eine Disziplinierungssoftware namens Oscillator für verschiedene Varianten der Zeitkarten zu entwickeln. Dies ist zum Standardtool geworden für:

Tatsächlich ermöglichen uns die von oscillatord exportierten Daten zu entscheiden, ob die Time Appliance Datenverkehr aufnehmen oder entleeren soll.

Unser oberstes Ziel ist es, Protokolle wie PTP über das Paketnetzwerk zu verbreiten. Und wenn die Time Card das schlagende Herz der Time Appliance ist, ist die Netzwerkkarte das Gesicht. Jedes zeitkritische PTP-Paket erhält von der Netzwerkkarte einen Hardware-Zeitstempel. Das bedeutet, dass die PTP-Hardwareuhr (PHC) der Netzwerkkarte genau diszipliniert sein muss.

Wenn wir die Uhrwerte einfach mit phc2sys oder einem ähnlichen Tool von der Time Card auf die Netzwerkkarte kopieren, reicht die Genauigkeit bei weitem nicht aus. Tatsächlich zeigen unsere Experimente, dass wir beim Durchlaufen von PCIe, CPU, NUMA usw. leicht etwa 1–2 Mikrosekunden verlieren würden. Die Leistung der Synchronisierung über den PCIe-Bus wird sich mit der aufkommenden Precision Time Measurement (PTM)-Technologie dramatisch verbessern Die Entwicklung und Unterstützung verschiedener Peripheriegeräte mit dieser Funktion ist im Gange.

Da wir für unsere Anwendung NICs mit PPS-Eingangsfunktionen verwenden, haben wir ts2phc verwendet, das zunächst Taktwerte kopiert und dann die Taktflanken basierend auf einem PPS-Signal (Pulse pro Sekunde) ausrichtet. Dazu ist ein zusätzliches Kabel zwischen dem PPS-Ausgang der Zeitkarte und dem PPS-Eingang der Netzwerkkarte erforderlich, wie im Bild unten gezeigt.

Wir überwachen ständig den Offset und stellen sicher, dass er niemals das ±50-ns-Fenster zwischen der Zeitkarte und der Netzwerkkarte überschreitet:

Wir überwachen auch die PPS-Out-Schnittstelle der Netzwerkkarte, um als Ausfallsicherung zu dienen und sicherzustellen, dass wir tatsächlich wissen, was mit dem PHC auf der Netzwerkkarte vor sich geht.

Bei der Evaluierung verschiedener bereits vorhandener PTP-Serverimplementierungen stießen wir auf Skalierbarkeitsprobleme sowohl bei Open-Source- als auch bei geschlossenen proprietären Lösungen, einschließlich der von uns evaluierten FPGA-beschleunigten PTP-Server. Im besten Fall könnten wir etwa 50.000 Clients pro Server erreichen. Bei unserem Maßstab bedeutet dies, dass wir viele Racks voller dieser Geräte bereitstellen müssten.

Da das Geheimnis von PTP in der Verwendung von Hardware-Zeitstempeln liegt, muss die Serverimplementierung kein hochoptimiertes C-Programm oder gar eine FPGA-beschleunigte Appliance sein.

Wir haben einen skalierbaren PTPv2-Unicast-PTP-Server in Go implementiert, den wir ptp4u nannten, und ihn als Open-Source-Version auf GitHub bereitgestellt. Mit einigen geringfügigen Optimierungen konnten wir über 1 Million gleichzeitige Clients pro Gerät unterstützen, was von einem IEEE 1588v2-zertifizierten Gerät unabhängig überprüft wurde.

Dies war durch die einfache, aber elegante Nutzung von Kanälen in Go möglich, die es uns ermöglichten, Abonnements zwischen mehreren leistungsstarken Mitarbeitern weiterzugeben.

Da ptp4u als Prozess auf einem Linux-Rechner läuft, erhalten wir automatisch alle Vorteile, wie IPv6-Unterstützung, Firewall usw., kostenlos.

Der ptp4u-Server verfügt über viele Konfigurationsoptionen, die es ihm ermöglichen, sich dynamisch ändernde Parameter zu übergeben, zGenauigkeit der PTP-Uhr,PTP-Uhrklasse,und einUTC-Offset– die derzeit auf 37 Sekunden eingestellt ist (wir gehen davon aus, dass dies eine Konstante wird) – abhängig von den Kunden.

Um diese Parameter häufig zu generieren, haben wir einen separaten Dienst namens c4u implementiert, der ständig mehrere Informationsquellen überwacht und die aktive Konfiguration für ptp4u kompiliert:

Dies gibt uns Flexibilität und Reaktionsfähigkeit, wenn sich die Umgebung ändert. Wenn wir beispielsweise das GNSS-Signal auf einem der Time Appliances verlieren, ändern wir die ClockClass auf HOLDOVER und die Clients migrieren sofort von ihr weg. Es berechnet auch die ClockAccuracy aus vielen verschiedenen Quellen, wie z. B. der ts2phc-Synchronisationsqualität, dem Atomuhrstatus usw.

Wir berechnen den UTC-Offset-Wert basierend auf dem Inhalt des tzdata-Pakets, da wir die Internationale Atomzeit (TAI) an die Clients weitergeben.

Wir wollten sicherstellen, dass unsere Time Appliances ständig und unabhängig von einem etablierten zertifizierten Überwachungsgerät bewertet werden. Glücklicherweise haben wir mit Calnex im NTP-Bereich bereits große Fortschritte gemacht und waren in der Lage, einen ähnlichen Ansatz auf PTP anzuwenden.

Wir haben mit Calnex zusammengearbeitet, um deren Feldgerät für den Einsatz im Rechenzentrum umzufunktionieren. Dazu mussten wir den physischen Formfaktor ändern und Unterstützung für Funktionen wie IPv6 hinzufügen.

Wir verbinden den NIC-PPS-Ausgang der Time Appliance mit dem Calnex Sentinel, wodurch wir den PHC des NIC mit Nanosekundengenauigkeit überwachen können.

Wir werden die Überwachung weiter unten im Abschnitt „Wie wir die PTP-Architektur überwachen“ ausführlich erläutern.

Das PTP-Protokoll unterstützt die Verwendung von Unicast- und Multicast-Modi für die Übertragung von PTP-Nachrichten. Bei großen Rechenzentrumsbereitstellungen wird Unicast gegenüber Multicast bevorzugt, da es das Netzwerkdesign und die Softwareanforderungen erheblich vereinfacht.

Werfen wir einen Blick auf einen typischen PTP-Unicast-Ablauf:

Ein Client startet die Verhandlung (Anforderung einer Unicast-Übertragung). Daher muss Folgendes gesendet werden:

Schematisch (nur zur Veranschaulichung) sieht es so aus:

Wir haben zunächst darüber nachgedacht, Boundary Clocks in unserem Design zu nutzen. Boundary Clocks bringen jedoch mehrere Nachteile und Komplikationen mit sich:

Um diese zusätzliche Komplexität zu vermeiden, haben wir uns entschieden, ausschließlich auf transparente PTP-Uhren zu setzen.

Transparente Uhren (TCs) ermöglichen es Clients, Schwankungen in der Netzwerklatenz zu berücksichtigen und so eine viel genauere Schätzung des Taktversatzes zu gewährleisten. Jeder Rechenzentrums-Switch im Pfad zwischen Client und Zeitserver meldet die Zeit, die jedes PTP-Paket beim Durchlaufen des Switches verbringt, indem er ein Feld in der Paketnutzlast aktualisiert, das treffend als Korrekturfeld (CF) bezeichnet wird.

PTP-Clients (auch als gewöhnliche Uhren oder OCs bezeichnet) berechnen die mittlere Pfadverzögerung des Netzwerks und Taktversätze zu den Zeitservern (Grandmaster Clocks oder GMs) mithilfe von vier Zeitstempeln (T1, T2, T3 und T4) und zwei Korrekturfeldwerten (CFa und CFb), wie im Diagramm unten dargestellt:

Um die Auswirkungen nur einer deaktivierten transparenten Uhr auf dem Weg zwischen Client und Server zu verstehen, können wir die Protokolle untersuchen:

Wir können sehen, dass die Pfadverzögerung explodiert und manchmal sogar negativ wird, was im normalen Betrieb nicht passieren sollte. Dies hat dramatische Auswirkungen auf den Offset und verschiebt ihn von ±100 Nanosekunden auf -400 Mikrosekunden (über 4000-fache Differenz). Und das Schlimmste von allem ist, dass dieser Offset nicht einmal genau ist, weil die Berechnungen der mittleren Pfadverzögerung falsch sind.

Unseren Experimenten zufolge können moderne Switches mit großen Puffern Pakete um bis zu ein paar Millisekunden verzögern, was zu einem Pfadverzögerungsberechnungsfehler von Hunderten von Mikrosekunden führt. Dies führt zu Offset-Spitzen und ist in den Diagrammen deutlich sichtbar:

Die Quintessenz ist, dass der Betrieb von PTP in Rechenzentren ohne TCs zu einer unvorhersehbaren und nicht rechenschaftspflichtigen Asymmetrie in der Roundtrip-Zeit führt. Und das Schlimmste: Es wird keine einfache Möglichkeit geben, dies zu erkennen. 500 Mikrosekunden klingen vielleicht nicht viel, aber wenn Kunden eine WOU von mehreren Mikrosekunden erwarten, kann dies zu einer SLA-Verletzung führen.

Das Zeitstempeln des eingehenden Pakets ist eine relativ alte Funktion, die seit Jahrzehnten vom Linux-Kernel unterstützt wird. Beispielsweise werden Software-(Kernel-)Zeitstempel seit Jahren von NTP-Daemons verwendet. Es ist wichtig zu verstehen, dass Zeitstempel nicht standardmäßig in der Paketnutzlast enthalten sind und bei Bedarf von der Benutzeranwendung dort platziert werden müssen.

Das Lesen des RX-Zeitstempels aus dem Benutzerbereich ist ein relativ einfacher Vorgang. Wenn das Paket ankommt, versieht die Netzwerkkarte (oder ein Kernel) dieses Ereignis mit einem Zeitstempel und fügt den Zeitstempel in die Socket-Steuernachricht ein. Dies lässt sich leicht mit dem Paket selbst vereinbaren, indem ein recvmsg-Systemaufruf mit gesetztem MSG_ERRQUEUE-Flag aufgerufen wird.

Für den TX-Hardware-Zeitstempel ist es etwas komplizierter. Wenn sendto syscall ausgeführt wird, führt dies nicht zu einem sofortigen Paketabgang und auch nicht zu einer TX-Zeitstempelgenerierung. In diesem Fall muss der Benutzer den Socket abfragen, bis der Zeitstempel vom Kernel korrekt platziert wird. Oft müssen wir mehrere Millisekunden warten, was natürlich die Sendegeschwindigkeit begrenzt.

Hardware-Zeitstempel sind das Geheimnis, das PTP so präzise macht. Die meisten modernen Netzwerkkarten unterstützen bereits Hardware-Zeitstempel, wobei der Netzwerkkartentreiber den entsprechenden Abschnitt ausfüllt.

Es ist sehr einfach, die Unterstützung zu überprüfen, indem Sie den Befehl ethtool ausführen:

Es ist weiterhin möglich, PTP mit Software-(Kernel-)Zeitstempeln zu verwenden, es gibt jedoch keine starken Garantien für deren Qualität, Präzision und Genauigkeit.

Wir haben diese Möglichkeit ebenfalls geprüft und sogar darüber nachgedacht, eine Änderung im Kernel zu implementieren, um die Hardware-Zeitstempel mit Software zu „fälschen“, bei der Hardware-Zeitstempel nicht verfügbar sind. Auf einem sehr ausgelasteten Host beobachteten wir jedoch, dass die Präzision der Software-Zeitstempel auf Hunderte von Mikrosekunden anstieg, und wir mussten diese Idee aufgeben.

ptp4l ist eine Open-Source-Software, die sowohl als PTP-Client als auch als PTP-Server fungieren kann. Während wir aus Leistungsgründen unsere eigene PTP-Serverlösung implementieren mussten, haben wir uns für den Client-Anwendungsfall entschieden, bei ptp4l zu bleiben.

Erste Tests im Labor ergaben, dass ptp4l sofort eine hervorragende Synchronisierungsqualität bieten und die Zeit auf den PHCs im lokalen Netzwerk auf den Bereich von mehreren zehn Nanosekunden anpassen kann.

Als wir jedoch begannen, unser Setup zu vergrößern, traten einige Probleme auf.

In einem bestimmten Beispiel bemerkten wir gelegentliche „Spitzen“ im Offset. Nach einem tiefen Einblick haben wir grundlegende Hardware-Einschränkungen einer der beliebtesten NICs auf dem Markt identifiziert:

Dies führte letztendlich dazu, dass die legitimen Zeitstempel durch Zeitstempel anderer Pakete ersetzt wurden. Aber was die Sache noch schlimmer machte: Der NIC-Treiber versuchte übermäßig clever zu sein und platzierte die Software-Zeitstempel im Hardware-Zeitstempel-Abschnitt der Socket-Steuerungsnachricht, ohne es jemandem zu sagen.

Es handelt sich um eine grundlegende Hardwarebeschränkung, die einen großen Teil der Flotte betrifft und nicht behoben werden kann.

Wir mussten einen Offset-Ausreißerfilter implementieren, der das Verhalten des PI-Servos veränderte und ihn zustandsbehaftet machte. Dies führte dazu, dass gelegentliche Ausreißer verworfen und die mittlere Häufigkeit während des Mikro-Holdovers festgelegt wurde:

Ohne diesen Filter hätte ptp4l die PHC-Frequenz sehr hoch gesteuert, was zu mehreren Sekunden Schwingung und schlechter Qualität im Fenster der Unsicherheit, das wir daraus erzeugen, führen würde.

Ein weiteres Problem ergab sich aus dem Design von BMCA. Der Zweck dieses Algorithmus besteht darin, die beste Time Appliance auszuwählen, wenn in der ptp4l.conf mehrere zur Auswahl stehen. Dies geschieht durch den Vergleich mehrerer Attribute, die von Zeitservern in Announce-Nachrichten bereitgestellt werden:

Das Problem manifestiert sich, wenn alle oben genannten Attribute gleich sind. BMCA verwendet die Time ApplianceMAC-Adresse als Tiebreaker, was bedeutet, dass unter normalen Betriebsbedingungen ein Time Server den gesamten Clientverkehr anzieht.

Um dem entgegenzuwirken, haben wir ein sogenanntes „Sharding“ eingeführt, bei dem verschiedene PTP-Clients verschiedenen Untergruppen von Time Appliances aus dem gesamten Pool zugewiesen werden.

Dadurch wurde das Problem nur teilweise behoben, da ein Server in jeder Untergruppe die gesamte Last für diese Gruppierung übernahm. Die Lösung bestand darin, den Kunden die Möglichkeit zu geben, eine Präferenz zu äußern, und so haben wir Priorität3 in die Auswahlkriterien direkt über dem MAC-Adressen-Tiebreaker eingeführt. Dies bedeutet, dass Clients, die für die Verwendung derselben Time Appliances konfiguriert sind, unterschiedliche Server bevorzugen können.

Kunde 1:

[unicast_master_table]

UDPv6 time_server1 1

UDPv6 time_server2 2

UDPv6 time_server3 3

Kunde 2:

[unicast_master_table]

UDPv6 time_server2 1

UDPv6 time_server3 2

UDPv6 time_server1 3

Dadurch wird sichergestellt, dass wir die Last unter normalen Betriebsbedingungen gleichmäßig auf alle Time Appliances verteilen können.

Eine weitere große Herausforderung für uns bestand darin, sicherzustellen, dass PTP mit Multi-Host-NICs funktioniert – mehrere Hosts teilen sich dieselbe physische Netzwerkschnittstelle und daher einen einzigen PHC. Allerdings hat ptp4l keine Kenntnis davon und versucht, den PHC zu disziplinieren, als gäbe es keine anderen Nachbarn.

Einige NIC-Hersteller haben einen sogenannten „Free Running“-Modus entwickelt, bei dem ptp4l lediglich die Formel im Kernel-Treiber diszipliniert. Der eigentliche PHC wird nicht beeinträchtigt und läuft weiterhin frei. Dieser Modus führt zu einer etwas schlechteren Präzision, ist für ptp4l jedoch völlig transparent.

Andere NIC-Hersteller unterstützen nur einen „Echtzeituhr“-Modus, bei dem der erste Host, der die Sperre ergreift, den PHC tatsächlich diszipliniert. Der Vorteil hierbei ist eine präzisere Kalibrierung und eine höhere Haltequalität, aber es führt zu einem separaten Problem, wenn ptp4l auf den anderen Hosts läuft, die dieselbe Netzwerkkarte verwenden, da Versuche, die PHC-Frequenz abzustimmen, keine Auswirkungen haben, was zu ungenauen Taktversatz- und Frequenzberechnungen führt.

Um die Konfiguration des Rechenzentrums zu beschreiben, haben wir ein PTP-Profil entwickelt und veröffentlicht, das die oben genannten Randfälle und viele mehr widerspiegelt.

Wir prüfen die Möglichkeit der Verwendung eines alternativen PTP-Clients. Unsere Hauptkriterien sind:

Wir evaluieren den Timebeat PTP-Client und bisher sieht er sehr vielversprechend aus.

Im PTP-Protokoll spielt es keine Rolle, welche Zeit wir weitergeben, solange wir einen UTC-Offset an die Clients weitergeben. In unserem Fall ist es die Internationale Atomzeit (TAI), einige Leute entscheiden sich jedoch möglicherweise für UTC. Wir betrachten die Zeit, die wir zur Verfügung stellen, gerne als einen kontinuierlich wachsenden Zähler.

Zu diesem Zeitpunkt disziplinieren wir nicht die Systemuhr und ptp4l wird ausschließlich zur Disziplinierung des PHC der Netzwerkkarte verwendet.

Die Synchronisierung von PHCs über die Serverflotte hinweg ist gut, bringt aber keinen Nutzen, es sei denn, es gibt eine Möglichkeit, diese Zahlen auf dem Client zu lesen und zu manipulieren.

Zu diesem Zweck haben wir eine einfache und leichte API namens fbclock entwickelt, die Informationen von PHC und ptp4l sammelt und leicht verdauliche Window Of Uncertainty-Informationen bereitstellt:

Über ein sehr effizientes ioctl PTP_SYS_OFFSET_EXTENDED erhält fbclock aktuelle Zeitstempel vom PHC und die neuesten Daten von ptp4l und wendet dann eine mathematische Formel an, um das Fenster der Unsicherheit (Window Of Uncertainty, WOU) zu berechnen:

Wie Sie vielleicht sehen, gibt die API nicht die aktuelle Uhrzeit zurück (auch bekannt als time.Now()). Stattdessen wird ein Zeitfenster zurückgegeben, das mit sehr hoher Wahrscheinlichkeit die tatsächliche Zeit enthält. In diesem speziellen Beispiel wissen wir, dass unser Unsicherheitsfenster 694 Nanosekunden beträgt und die Zeit zwischen (TAI) Donnerstag, 2. Juni 2022, 17:44 Uhr liegt: 08:711023134 und Donnerstag, 02. Juni 2022 17:44:08:711023828.

Dieser Ansatz ermöglicht es Kunden, zu warten, bis das Intervall abgelaufen ist, um eine genaue Transaktionsreihenfolge sicherzustellen.

Die Messung der Genauigkeit der Zeit oder (Fenster der Unsicherheit) bedeutet, dass neben dem gelieferten Zeitwert ein Fenster (ein Plus-/Minus-Wert) angezeigt wird, das garantiert die wahre Zeit mit einem hohen Maß an Sicherheit einschließt.

Wie sicher wir sein müssen, hängt davon ab, wie wichtig es ist, dass die Zeit korrekt ist, und dies hängt von der jeweiligen Anwendung ab.

In unserem Fall muss diese Sicherheit besser als 99,9999 % (6-9 s) sein. Bei dieser Zuverlässigkeit können Sie mit weniger als einem Fehler pro 1.000.000 Messungen rechnen.

Die Fehlerratenschätzung nutzt die Beobachtung des Datenverlaufs (Histogramm), um eine Wahrscheinlichkeitsverteilungsfunktion (PDF) anzupassen. Aus der Wahrscheinlichkeitsverteilungsfunktion kann man die Varianz berechnen (eine Quadratwurzel nehmen und die Standardabweichung ermitteln) und von dort aus eine einfache Multiplikation durchführen, um die Schätzung der Verteilung basierend auf ihrem Wert zu erhalten.

Unten sehen Sie ein Histogramm aus der Offset-Messung von ptp4l, das auf der normalen Uhr läuft.

Um die Gesamtvarianz (E2E) abzuschätzen, muss die Varianz des vom Zeitserver bis zur Endknoten-NIC akkumulierten Zeitfehlers bekannt sein. Dazu gehören GNSS, Atomuhr und Time Card PHC to NIC PHC (ts2phc). Der Hersteller gibt die GNSS-Fehlervarianz an. Beim UBX-F9T sind es etwa 12 Nanosekunden. Für die Atomuhr hängt der Wert von der Disziplinierungsschwelle ab, die wir festgelegt haben. Je strenger die Disziplinierungsschwelle, desto geringer ist die Offset-Varianz, aber desto geringer ist die Holdover-Leistung. Zum Zeitpunkt der Durchführung dieses Experiments wurde die Fehlervarianz der Atomuhr mit 43 ns (Standardabweichung, Standard) gemessen. Schließlich erhöht das Tool ts2phc die Varianz um 30 ns (Standard), was zu einer Gesamtvarianz von 52 ns führt.

Die beobachteten Ergebnisse stimmen mit der berechneten Varianz überein, die durch das „Gesetz der Varianzsumme“ ermittelt wurde.

Nach dem Varianzsummengesetz müssen wir lediglich die gesamte Varianz addieren. In unserem Fall wissen wir, dass der gesamte Beobachter-E2E-Fehler (gemessen über den Calnex Sentinel) etwa 92 ns beträgt.

Andererseits können wir für unsere Schätzung Folgendes haben:

Geschätzte E2E-Varianz = [GNSS-Varianz + MAC-Varianz + ts2phc-Varianz] + [PTP4L-Offset-Varianz] = [Zeitserver-Varianz] + [Ordinary-Clock-Varianz]

Einsetzen der Werte:

Geschätzte E2E-Varianz = (12 ns 2) + (43 ns2) + (52 ns2) + (61 ns2) = 8418, was 91,7 ns entspricht

Diese Ergebnisse zeigen, dass durch die Ausbreitung der Fehlervarianz im Taktbaum die E2E-Fehlervarianz mit guter Genauigkeit geschätzt werden kann. Die E2E-Fehlervarianz kann zur Berechnung des Fensters der Unsicherheit (Window Of Uncertainty, WOU) basierend auf der folgenden Tabelle verwendet werden.

Indem wir einfach die geschätzte E2E-Fehlervarianz mit 4,745 multiplizieren, können wir das Fenster der Unsicherheit für die Wahrscheinlichkeit von 6–9 schätzen.

Für unser gegebenes System beträgt die Wahrscheinlichkeit von 6-9s etwa 92 ns x 4,745 = 436 ns

Dies bedeutet, dass bei einer von PTP gemeldeten Zeit unter Berücksichtigung einer Fenstergröße von 436 ns um den Wert garantiert wird, dass die tatsächliche Zeit mit einer Konfidenz von über 99,9999 % enthalten ist.

Auch wenn all das oben Genannte logisch und großartig erscheint, gibt es darin eine große Annahme. Es wird davon ausgegangen, dass die Verbindung zum offenen Zeitserver (OTS) verfügbar ist und sich alles im normalen Betriebsmodus befindet. Viele Dinge können schief gehen, wie z. B. ein Ausfall des OTS, ein Ausfall des Schalters, ein nicht ordnungsgemäßes Verhalten von Sync-Nachrichten, eine Entscheidung dazwischen, die Bereitschaftsdienste aufzuwecken usw. In einer solchen Situation sollte die Berechnung der Fehlergrenze erfolgen Wechseln Sie in den Holdover-Modus. Das Gleiche gilt für das OTS, wenn GNSS ausfällt. In einer solchen Situation erhöht das System das Fenster der Unsicherheit basierend auf einem zusammengesetzten Zinssatz. Die Rate wird basierend auf der Stabilität des Oszillators (Scrollvarianz) während des normalen Betriebs geschätzt. Beim OTS wird die zusammengesetzte Rate durch die genaue Telemetrieüberwachung des Systems (Temperatur, Vibration usw.) angepasst. Hier liegt eine Menge Arbeit darin, die Koeffizienten zu kalibrieren und das beste Ergebnis zu erzielen, und wir arbeiten immer noch an diesen Feinabstimmungen.

Während der Zeiträume, in denen die Netzwerksynchronisation verfügbar ist, passt der Servo ständig die Frequenz des lokalen Takts auf der Client-Seite an (vorausgesetzt, der anfängliche Schritt führte zu einer Konvergenz). Bei einer Unterbrechung der Netzwerksynchronisierung (durch den Verlust der Verbindung zum Zeitserver oder durch den Ausfall des Zeitservers selbst) bleibt der Servo mit einem letzten Frequenzkorrekturwert zurück. Daher soll es sich bei diesem Wert nicht um eine Schätzung der Präzision der lokalen Uhr handeln, sondern vielmehr um eine vorübergehende Frequenzanpassung, um den zwischen der Cline und dem Zeitserver gemessenen Zeitfehler (Offset) zu verringern.

Daher ist es notwendig, erstens Synchronisationsverlustperioden zu berücksichtigen und die beste Schätzung der Frequenzkorrektur zu verwenden (normalerweise den gleitenden Durchschnitt vorheriger Korrekturwerte) und zweitens den Anstieg der Fehlergrenze zu berücksichtigen, indem man den letzten Korrekturwert betrachtet und vergleicht mit dem gleitenden Durchschnitt der vorherigen Korrekturwerte.

Die Überwachung ist einer der wichtigsten Teile der PTP-Architektur. Aufgrund der Art und Wirkung des Dienstes haben wir ziemlich viel Zeit mit der Entwicklung der Werkzeuge verbracht.

Wir haben mit dem Calnex-Team zusammengearbeitet, um die Sentinel-HTTP-API zu erstellen, die es uns ermöglicht, Daten vom Gerät zu verwalten, zu konfigurieren und zu exportieren. Bei Meta haben wir ein API-Befehlszeilentool erstellt und als Open-Source-Lösung bereitgestellt, das menschliche und skriptfreundliche Interaktionen ermöglicht.

Mit Calnex Sentinel 2.0 sind wir in der Lage, drei Hauptmetriken pro Zeiteinheit zu überwachen – NTP, PTP und PPS.

Dadurch können wir Techniker über jedes Problem mit den Geräten informieren und genau erkennen, wo das Problem liegt.

In diesem Fall erreichen beispielsweise sowohl die PTP- als auch die PPS-Überwachung eine Variation von etwa weniger als 100 Nanosekunden über 24 Stunden, während NTP innerhalb von 8 Mikrosekunden bleibt.

Um unser Setup zu überwachen, haben wir ein Tool namens ptpcheck implementiert und als Open-Source-Lösung bereitgestellt. Es gibt viele verschiedene Unterbefehle, aber die interessantesten sind die folgenden:

Der Unterbefehl „Client“ liefert einen Gesamtstatus eines PTP-Clients. Es meldet den Zeitpunkt des Empfangs der letzten Sync-Nachricht, den Zeitversatz zum ausgewählten Zeitserver, die mittlere Pfadverzögerung und andere hilfreiche Informationen:

Client-Unterbefehl, der das Abfragen einer fbclock-API und das Abrufen eines aktuellen Fensters der Unsicherheit ermöglicht:

Die Client-Überwachung im Chrony-Stil ermöglicht die Anzeige aller in der Client-Konfigurationsdatei konfigurierten Zeitserver, ihres Status und ihrer Zeitqualität.

Server-Unterbefehl, ermöglicht das Lesen einer Zusammenfassung von der Zeitkarte.

Wir können beispielsweise erkennen, dass die letzte Korrektur auf der Zeitkarte nur 1 Nanosekunde betrug.

Mit diesem Unterbefehl können wir einen Unterschied zwischen zwei beliebigen PHCs ermitteln:

In diesem speziellen Fall beträgt der Unterschied zwischen der Zeitkarte und einer Netzwerkkarte auf einem Server -15 Nanosekunden.

Es ist gut, die Überwachung regelmäßig oder bei Bedarf auszulösen, aber wir wollen noch weiter gehen. Wir wollen wissen, was der Kunde tatsächlich erlebt. Zu diesem Zweck haben wir mehrere Buckets direkt in die fbclock-API eingebettet, die auf atomaren Zählern basieren, die sich jedes Mal erhöhen, wenn der Client eine API aufruft:

Dadurch können wir deutlich erkennen, wann beim Kunden ein Problem auftritt – und oft sogar, bevor der Kunde es überhaupt bemerkt.

Das PTP-Protokoll (und insbesondere ptp4l) verfügt über keinen Quorum-Auswahlprozess (im Gegensatz zu NTP und Chrony). Das bedeutet, dass der Client den Zeitserver basierend auf den über Announce-Nachrichten bereitgestellten Informationen auswählt und ihm vertraut. Dies gilt auch dann, wenn der Zeitserver selbst falsch ist.

Für solche Situationen haben wir eine letzte Verteidigungslinie namens Linearisierbarkeitsprüfung implementiert.

Stellen Sie sich eine Situation vor, in der ein Client für die Verwendung von drei Zeitservern konfiguriert ist und der Client einen fehlerhaften Zeitserver abonniert hat (z. B. Zeitserver 2):

In dieser Situation geht der PTP-Client davon aus, dass alles in Ordnung ist, aber die Informationen, die er der Anwendung zeitaufwändig zur Verfügung stellt, sind falsch, da das Fenster der Unsicherheit verschoben und daher ungenau ist.

Um dem entgegenzuwirken, baut die fbclock parallel die Kommunikation mit den übrigen Zeitservern auf und vergleicht die Ergebnisse. Wenn die Mehrzahl der Offsets hoch ist, bedeutet dies, dass der Server, dem unser Client folgt, der Ausreißer ist und der Client nicht linearisierbar ist, selbst wenn die Synchronisierung zwischen Zeitserver 2 und dem Client perfekt ist.

Wir glauben, dass PTP in den kommenden Jahrzehnten zum Standard für die Zeitmessung in Computernetzwerken werden wird. Deshalb setzen wir es in einem beispiellosen Ausmaß ein. Wir mussten unseren gesamten Infrastruktur-Stack – von der GNSS-Antenne bis hin zur Client-API – kritisch unter die Lupe nehmen und haben in vielen Fällen sogar Dinge von Grund auf neu aufgebaut.

Während wir die Einführung von PTP fortsetzen, hoffen wir, dass mehr Anbieter, die Netzwerkgeräte herstellen, unsere Arbeit nutzen werden, um der Branche neue Geräte zur Verfügung zu stellen, die PTP unterstützen. Wir haben den Großteil unserer Arbeit als Open-Source-Lösung bereitgestellt, von unserem Quellcode bis hin zu unserer Hardware, und wir hoffen, dass die Branche sich uns anschließen wird, um PTP der Welt zugänglich zu machen. All dies geschah im Namen der Steigerung der Leistung und Zuverlässigkeit der bestehenden Lösungen, aber auch im Hinblick auf die Erschließung neuer Produkte, Dienstleistungen und Lösungen in der Zukunft.

Wir möchten allen an diesem Unterfangen Beteiligten danken, von Metas internen Teams bis hin zu Anbietern und Herstellern, die mit uns zusammenarbeiten. Besonderer Dank geht an Andrei Lukovenko, der Zeitbegeisterte zusammengebracht hat.

Diese Reise ist erst zu einem Prozent abgeschlossen.