NTP Loopstat und Peerstat

orm@doc-tcpip.org

Erstellt: November 2002 - Letzte Modifikation: November 2002

Die Auswertung der NTP Statistiken

Die Umgebung

Die Daten stammen von IBM RS6000 Maschinen, einer 43P 170 als Stratum 1 Server, der seine Zeit über das Internet von der Physikalisch-Technischen Bundesanstalt in Braunschweig holt. Der Client ist eine 43P 270.

Das Vorgehen

Der xntpd wurde mit folgenden Einstellungen zum Loggen gebracht:

statsdir /tmp/       
 filegen peerstats  file peerstats  type day enable
 filegen loopstats  file loopstats  type day enable

So wird jeden Tag ein File mit den tagsüber aufgelaufenen Werten weggeschrieben. Diese Files wurden mit GNUplot ausgewertet, wobei die ersten, disparaten Werte nicht beachtet wurden.

Aufgetragen wurde einmal der relative Frequenz-Offset gegen die Zeit, der Zeit-Offset gegen die Zeit und, eher als Gag, der Polling Interval gegen die Zeit. Das kann man mit solchen GNUplot-Befehlen direkt aus den Stat-Files erzeugen:
plot "loopstats.20021004" using ($2/3600):4 title 'Frequenz Offset'
(es wird direkt durch 3600 geteilt, um die Stunden zu erhalten).

Der Zeit-Server

Der xntpd wurde morgens konfiguriert und gestartet. Der zeitliche Offset zum Server der PTB lag da bei etwa 4 ms. Im Zug der Syncronisation und Syntonisation hat der xntpd dieser Maschine die Frequenz- und Phasenverschiebung zur Referenz immer besser herausgearbeitet. Ungefähr nach 3 Stunden hat sich die Lage stabilisiert. Die absolute Höhe des Frequenz-Offsets ist nicht wichtig, es kommt auf die Schwankung an. Diese ist hier mittelprächtig, etwas weniger als ein halbes ppm ist nicht toll, aber auch nicht schlecht. Das akzentuiert sich beim zeitlichen Offset, der rund 2 ms beträgt und nicht zur Ruhe kommt. Besonders diese Kurve sollte nicht ganz so zackig sein, glattere Übergänge wären wünschenswert. Ab 20:00 Uhr wird es deutlich besser - offensichtlich sind die Türen zu und die Klimaanlage kann vernünftig arbeiten. Man sieht auch, das ab jetzt der Server wesentlich weniger oft in Braunschweig anklopft...

Um den Zusammenhang von stabiler Frequenz (und damit Zeit-Offset) und dem Polling-Interval, also die Häufigkeit des Abgleichs mit dem Server, darzustellen wurde der Frequenz-Offset gegen den Log2 des Polling Intervals aufgetragen. Der Interval geht von 6 bis 10, also 64 bis 1024 Sekunden. Man kann sehr gut die Steigung der Kurve mit heftigerem Pollen in Verbindung setzen. Die ruhige Phase Nachts pendelt sich bei 1024 Sekunden ein, was der gesetzte maxpoll Wert ist.

Weil es so schön ist, hier noch den zweiten Tag. Die Beobachtungen vom Vortag wiederholen sich. Nachts und am frühen Morgen ist alles sehr schön, auch wenn der Zeit-Offset immer noch recht kantig ist. Eigentlich müßte man für diese Zeit der Ruhe eine eigene Auswertung machen, dann könnte man recht gut sehen, wie Stabil diese Maschine in der Umgebung werden könnte.. (Soviel sei verraten: die Schwankung des Frequenz-Offset liegt so bei 0.1 ppm/4 h in diesem Fall). Der Zeit-Offset schwankt um etwa 0.3 ms, was ok ist. Dann reißt um 12:00 jemand die Türe auf und die ungeeignete Klimaanlage geht in die Knie, worauf der Tanz wieder anfängt. Wir kommen kurz vor 15:00 auf etwa 0.5 ppm Änderung in einer knappen Stunde. Da kann man nicht auf Besserung hoffen.

Der Vollständigkeit halber die Auftragung von Frequenz-Offset und Polling-Interval.

Zum Schluß noch die Auftragung ohne die ersten Stunden nach dem Boot und über mehrere Tage. Das macht die Skala kleiner, sodaß man einen leichteren Überblick hat. Man sieht die großen Schwankungen tagüber, und die Ruhe nachts. Am dritten Tag hat der anscheinend der Referenz-Server gewechselt, oder im Rechenzentrum gab es ein Problem.

Es sei nochmal betont: die Schwankunen an- und für sich sind nicht das Problem (0.4 ppm, wenn wir von dem Sprung um den 4. Tag absehen). Schlimm ist die große Geschwindigkeit der Änderungen. Und diese Maschine ist ja Zeit-server für andere! Da sind 0.4 ppm pro Stunde schon sehr happig. Alles sehr eigenartig und nicht zur Nachahmung geeignet.

Ein Client

Wie hat jetzt der Client die letzten zwei Tage erlebt?
Die Schwankungen des Frequenz-Offset sind weniger betont, aber kommen immer noch sehr schnell (0.5 in etwa eine halben Stunde um 22:00). Das tut weh. Der Zeitoffset reagiert entsprechend nervös. Der Frequenz-Offset ist gering, Client und Server stehen offensichtlich nach bei einander.

Am nächsten Tag ist es deutlich besser. Für einen Client ist das in Ordnung, der Zeit-Offset ist im Bereich von 2 ms, der Frequenz-Offset bis auf einen Ausreißer deutlich unter 0.5 ppm, keine heftigen Schwankungen. Der Zeit-Offset liegt um eine ms, man würde sich nur wünschen, das es alles etwas runder, weniger betont, geht.

Wie man einen Server prüfen kann

Dabei ist das Problem, das man selbst eine sehr gute Zeitquelle haben muß, den sonst kann man keine Aussage machen. Dieses Beispiel zeigt wirklich nur die Methode, mit obigem "Zeit-Server" kann man nichts messen.

Macht man solche Messungen mit einem guten Server, dann entsteht ein Keil, der sich nach rechts öffnet. Auf der x-Achse ist der Delay aufgetragen - wie weit also der Rechner weg ist. Das ist natürlich eine klare Grenze, denn schneller als das Licht geht nicht. Die Streuung nach rechts gibt ein Maß für die Zuverläßigkeit des Netzwerkes bzw. den Fehlern, die man sich da einfängt. Die Streuung in vertikaler Richtung, also der Öffnungs-Winkel des Kegels, würde eine Aussage über die Qualität des Servers (immer im Vergleich zum messenden Server!) zulassen.

Das sich hier zwei Häufungs-Punkte gebildet haben, liegt daran, das es offenbar zwei Wege zu den Servern gibt. Entweder wird ab und an mal anders geroutet, oder irgendeine Komponente auf dem Weg hat die Hufe hochgerissen und ein anderer Weg wurde beschritten. Das konnte man näher untersuchen, wenn man die zeitliche Abfolge der Messwerte heranzieht - ist aber eigentlich total egal.

[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]