5. Implementation Model (Implementierungsmodell)
Abbildung 2 zeigt die Architektur einer typischen Multi-Thread-Implementierung (multi-threaded implementation). Sie umfasst zwei für jeden Server dedizierte Prozesse, einen Peer-Prozess (peer process) zum Empfang von Nachrichten vom Server oder der Referenzuhr, und einen Abfrageprozess (poll process) zur Übertragung von Nachrichten an den Server oder die Referenzuhr.
.....................................................................
. Remote . Peer/Poll . System . Clock .
. Servers . Processes . Process .Discipline.
. . . . Process .
.+--------+. +-----------+. +------------+ . .
.| |->| |. | | . .
.|Server 1| |Peer/Poll 1|->| | . .
.| |<-| |. | | . .
.+--------+. +-----------+. | | . .
. . ^ . | | . .
. . | . | | . .
.+--------+. +-----------+. | | +-----------+. .
.| |->| |. | Selection |->| |. +------+ .
.|Server 2| |Peer/Poll 2|->| and | | Combine |->| Loop | .
.| |<-| |. | Cluster | | Algorithm |. |Filter| .
.+--------+. +-----------+. | Algorithms |->| |. +------+ .
. . ^ . | | +-----------+. | .
. . | . | | . | .
.+--------+. +-----------+. | | . | .
.| |->| |. | | . | .
.|Server 3| |Peer/Poll 3|->| | . | .
.| |<-| |. | | . | .
.+--------+. +-----------+. +------------+ . | .
....................^.........................................|......
| . V .
| . +-----+ .
+--------------------------------------| VFO | .
. +-----+ .
. Clock .
. Adjust .
. Process .
............
Abbildung 2: Implementierungsmodell
Diese Prozesse arbeiten auf einer gemeinsamen Datenstruktur, genannt Assoziation (association), die die oben beschriebenen Statistiken sowie verschiedene andere in Abschnitt 9 beschriebene Daten enthält. Ein Client sendet Pakete an einen oder mehrere Server und verarbeitet dann die zurückgegebenen Pakete, wenn sie empfangen werden. Der Server tauscht Quell- und Zieladressen sowie Ports aus, überschreibt bestimmte Felder im Paket und gibt es sofort zurück (im Client/Server-Modus) oder zu einem späteren Zeitpunkt (in den symmetrischen Modi). Wenn jede NTP-Nachricht empfangen wird, wird der Versatz (offset, theta) zwischen der Peer-Uhr und der Systemuhr zusammen mit den zugehörigen Statistiken delta, epsilon und psi berechnet.
Der Systemprozess (system process) umfasst die Auswahl (selection)-, Cluster- und Kombinationsalgorithmen (combine algorithms), die zwischen den verschiedenen Servern und Referenzuhren vermitteln, um die genauesten und zuverlässigsten Kandidaten zur Synchronisierung der Systemuhr zu bestimmen. Der Auswahlalgorithmus verwendet byzantinische Fehlererkennungsprinzipien (Byzantine fault detection principles), um die vermutlich inkorrekten Kandidaten, genannt "Falsetickers", aus der eingehenden Population zu verwerfen und nur gute Kandidaten, genannt "Truechimers", zu belassen. Ein Truechimer ist eine Uhr, die die Zeitmessungsgenauigkeit gemäß einem zuvor veröffentlichten und vertrauenswürdigen Standard aufrechterhält, während ein Falseticker eine Uhr ist, die irreführende oder inkonsistente Zeit anzeigt. Der Cluster-Algorithmus verwendet statistische Prinzipien, um die genaueste Menge von Truechimers zu finden. Der Kombinationsalgorithmus berechnet den endgültigen Uhrenversatz durch statistisches Mitteln der überlebenden Truechimers.
Der Uhrenkontrollprozess (clock discipline process) ist ein Systemprozess, der die Zeit und Frequenz der Systemuhr steuert, hier dargestellt als ein variabler Frequenzoszillator (variable frequency oscillator, VFO). Vom VFO erzeugte Zeitstempel schließen die Rückkopplungsschleife (feedback loop), die die Systemuhrzeit aufrechterhält. Dem Uhrenkontrollprozess zugeordnet ist der Uhrenanpassungsprozess (clock-adjust process), der einmal pro Sekunde läuft, um einen berechneten Zeitversatz einzufügen und eine konstante Frequenz aufrechtzuerhalten. Der RMS-Durchschnitt vergangener Zeitversatzunterschiede repräsentiert den nominalen Fehler oder das Systemuhr-Jitter (system clock jitter). Der RMS-Durchschnitt vergangener Frequenzversatzunterschiede repräsentiert die Oszillatorfrequenzstabilität (oscillator frequency stability) oder Frequenzwanderung (frequency wander). Diese Begriffe erhalten eine präzise Interpretation in Abschnitt 11.3.
Ein Client sendet Nachrichten an jeden Server mit einem Abfrageintervall (poll interval) von 2^tau Sekunden, wie durch den Abfrageexponenten (poll exponent) tau bestimmt. In NTPv4 reicht tau von 4 (16 s) bis 17 (36 h). Der Wert von tau wird durch den Uhrenkontrollalgorithmus bestimmt, um der Schleifen-Zeitkonstante (loop-time constant) T_c = 2^tau zu entsprechen. Im Client/Server-Modus antwortet der Server sofort; in symmetrischen Modi verwaltet jedoch jeder der beiden Peers tau als Funktion des aktuellen Systemversatzes und des System-Jitters, sodass sie möglicherweise nicht denselben Wert vereinbaren. Es ist wichtig, dass das dynamische Verhalten des Uhrenkontrollalgorithmus sorgfältig kontrolliert wird, um die Stabilität im NTP-Subnetz insgesamt aufrechtzuerhalten. Dies erfordert, dass die Peers sich auf ein gemeinsames tau einigen, das dem minimalen Abfrageexponenten beider Peers entspricht. Das NTP-Protokoll enthält Vorkehrungen zur ordnungsgemäßen Aushandlung dieses Wertes.
Das Implementierungsmodell umfasst einige Mittel zum Einstellen und Anpassen der Systemuhr. Es wird angenommen, dass das Betriebssystem zwei Funktionen bereitstellt: eine zum direkten Einstellen der Zeit, zum Beispiel die Unix-Funktion settimeofday(), und eine andere zum Anpassen der Zeit in kleinen Schritten, die die Zeit um einen bestimmten Betrag vorwärts oder rückwärts bewegt, zum Beispiel die Unix-Funktion adjtime(). In dieser und den folgenden Referenzen zeigen Klammern nach einem Namen eine Referenz auf eine Funktion anstelle einer einfachen Variablen an. Im vorgesehenen Design verwendet der Uhrenkontrollprozess die Funktion adjtime(), wenn die Anpassung kleiner als ein festgelegter Schwellenwert ist, und die Funktion settimeofday(), wenn sie über dem Schwellenwert liegt. Die Art und Weise, wie dies geschieht, und der Wert des Schwellenwerts werden in Abschnitt 10 beschrieben.