Wie kann ich eine Zeitverschiebung messen und verhindern?

15

Auf mehreren Produktionsplattformen haben wir Symptome beobachtet, die darauf hindeuten, dass die Uhrzeit regelmäßig vorwärts oder rückwärts springt. Die Sprünge dauern in der Regel ungefähr 1 Sekunde, werden normalerweise abgebrochen (springen Sie kurz danach vorwärts und zurück) und treten ungefähr 50 Mal pro Tag auf. Diese Abweichung ist am deutlichsten in Zeiten mit hoher Anwendungsauslastung und bei E / A-Vorgängen mit hohem Datenaufkommen, z. B. täglichen Sicherungen, zu beobachten. Diese Abweichungen wirken sich auf unsere weiche, echtzeitempfindliche Anwendung aus.

Systeme sind Oracle Netra X4250- und Netra X4270-Server, auf denen SLES 11SP2 mit dem Standardkernel 3.0.58-0.6.6 ausgeführt wird.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Wir haben NTP deaktiviert , aber das hat keinen Einfluss auf die Abweichungen. Gibt es Tools, die die Zeit der Zeitverschiebung messen? Wie können wir das vermeiden?

Dies sind Produktionsplattformen, und wir können das Problem in unseren Labors nicht nachvollziehen, sodass meine Experimentierfähigkeit eingeschränkt ist. Wenn links nach meinen eigenen Geräten, werde ich ein Werkzeug zur Messung der Drift, schreiben und vielleicht mit einem Experiment HPET Clock.

linux sles clock

— Brett
quelle

5

Durch das Deaktivieren von NTP werden Uhren sehr viel instabiler. Der einzige Grund, warum NTP die Uhr nicht auf dem neuesten Stand hält, ist, dass die Uhr nicht auf dem neuesten Stand ist und NTP sich weigert, sie zu aktualisieren (siehe ntpdate(8)oder ntpd(8)).

— Vonbrand

1

NTPD verfolgt und korrigiert die Zeitverschiebung, aber was Sie haben, ist keine Zeitverschiebung. Die Drift verläuft über die Zeit konstant in die gleiche Richtung. Wenn es zufällig vorwärts und rückwärts springt, gibt es keine Möglichkeit, es vorherzusagen und es zu berücksichtigen.

— Patrick

1

Was @Patrick sagte, ist richtig, das Problem, das Sie beschreiben, ist ein diskontinuierlicher Zeitsprung vorwärts und rückwärts, mehrmals pro Tag. NTP funktioniert gut auf Drift, aber es wird Ihnen nicht viel dabei helfen. Wahrscheinlich wird Ihr Systemdatum auf eine externe Zeitquelle zurückgesetzt, die möglicherweise nur eine Auflösung von 1 Sekunde hat. Wenn Ihre Server x86 * sind, ist möglicherweise die Hardware-RTC die Quelle und ein Cron-Job der Schuldige. Was die Messung des Zeitversatzes angeht, ist Bratchleys NTPdate-Antwort ein vernünftiger Ansatz, vorausgesetzt, es wird eine gute Zeitreferenz für Schicht 1 verwendet: einmal pro Minute ausführen und das Ergebnis für ein Bild gnuplotten.

— Duanev

1

Stieß auf diese Bewertung von NTP beim Starten auf einem neuen Server ( drdobbs.com/embedded-systems/… ). Das Erlernen eines neuen Kristalls dauert NTP-Stunden. Für wirklich schlechte Kristalle muss NTP die Uhr während des Trainings um ein Vielfaches "schrittweise" bewegen (siehe Abb. 4 und 5 in diesem Artikel). Ein Endwert für die NTP-Abweichung von 118 ppm beträgt 10 Sekunden pro Tag oder 208 ms alle 30 Minuten. Obwohl das OP dies nicht sah, kann NTP zunächst zu merklichen Zeitsprüngen führen.

— Duanev

8

Gibt es Tools, die die Zeit der Zeitverschiebung messen?

Die einzigen Tools, die mir bekannt sind, sind die NTP-Tools, die ausreichen sollten. Sie müssen ntpd nicht wirklich so konfigurieren, dass es mit einer bestimmten Taktquelle synchronisiert, für die Sie nur die -dOption verwenden könnenntpdate , um den berechneten Offset abzurufen.

Beispiel:

[davisja5@xxxadmvlm08 ~]$ ntpdate -d clock.redhat.com 2>/dev/null | egrep "^offset"
offset -0.004545
[davisja5@xxxadmvlm08 ~]$

-d ist die Debug-Option, mit der das NTP funktioniert, ohne die Systemuhr zu berühren.

Irgendwelche Ratschläge, wie wir dies vermeiden können?

Es überrascht mich nicht, dass Sie dies nicht in Entwicklungs- / Testumgebungen reproduzieren können, da es wahrscheinlich nur an der Hardware-Uhr liegt. Wenn Sie mit jemandem Hardware-Support haben, würde ich versuchen, Ihre Maschinen warten zu lassen. Eine Möglichkeit besteht darin, eine der Entwicklungsmaschinen für diese Produktionsmaschine auszutauschen, die früheren PROD-Systeme zu reparieren und sie wieder als Entwicklungsmaschine einzuführen, um die derzeit in PROD vorhandene zu ersetzen.

Kurz gesagt, das Umschalten der Hardware-Taktquelle ist fast alles, was Sie tun können. Wenn Sie den Tausch nicht machen oder nicht machen können, würde ich vorschlagen, dass Sie den HPET-Weg gehen. Sie können testen, ob die Änderung der Taktquelle mit den Systemdiensten in Konflikt gerät, und diese dann als Hagelsturm in der Produktion bereitstellen.

— Bratchley
quelle

Mit "Clock-Drift messen" meine ich nicht Drift aus einer Referenzzeitquelle, wie Sie sie von NTP kennen. Ich meinte ein Werkzeug, das "Sprünge" in der Tageszeituhr über einen kontinuierlichen Zeitbereich erfassen kann. Nehmen Sie beispielsweise alle 50 ms eine Tageszeitmessung vor und geben Sie an, ob die Differenz zur letzten Probenahme zu weit von 50 ms entfernt ist. Ein solches Tool würde zeigen, ob die Uhrzeit aus irgendeinem Grund von der zugrunde liegenden Hardwareuhr abweicht.

— Brett

1

Würde das Vorhandensein eines solchen Eingriffs nicht wahrscheinlich mehr Leistungseinbußen verursachen, als Sie zu beheben hoffen? Aller Wahrscheinlichkeit nach handelt es sich jedoch um ein Hardwareproblem, sodass Sie die Hardware warten lassen oder eine Taktquelle verwenden müssen, ohne dass dieses Problem auftritt. tscbasiert auf der CPU, daher ist es sinnvoll, dass eine höhere CPU-Aktivität sowieso ein Problem mit der Hardware-Uhr auslösen würde. Wenn HPET für Sie schnell genug ist, müssen Sie es möglicherweise nur versuchen, sich warten lassen oder den Tausch durchführen. Dies sind die einzigen Optionen, die ich für Sie sehen kann.

— Bratchley

3

Eine Lösung ist zu verwenden HPET

Siehe auch High Precision Event Timer

Verwenden Sie zum Festlegen als Boot-Parameter

clocksource=hpet

Auf älterer Hardware TSCwar die oft instabil und wurde vom Kernel deaktiviert.

Mit dem Aufkommen von Multi-Core- / Hyper-Threaded-CPUs, Systemen mit mehreren CPUs und Betriebssystemen im Ruhezustand kann die TSC keine genauen Ergebnisse liefern ...

Wikipedia: Zeitstempelzähler

Auf einem Produktionssystem, das die Clock-Jitter-Symptome aufweist, habe ich die Clock-Quelle auf HPET umgestellt. Dies hatte keinen Einfluss auf die beobachteten Clock-Jitter-Symptome.

— Brett

HPET ist ein externer Hardware-Timer und kann nicht zittern. Diese Lösung scheint also ein falscher Weg zu sein. Es gab viele Zeitprobleme mit älterer Hardware, insbesondere bei der Verwendung von Virtualisierung. Haben Sie dies auch mit einer anderen Software überprüft?

1

Ich habe ein detaillierteres Tool geschrieben, um die Taktmessungen mit den Latenzsymptomen unserer Anwendung zu korrelieren. Dieses Tool scheint auszuschließen, was ich bisher als Jitter in der Linux-Tageszeit vermutet habe.

Meine anfängliche Hypothese war ungültig. Aber ich habe durch die Antworten und Links viel über Linux-Uhren gelernt. Vielen Dank an alle, die geantwortet haben!

— Brett
quelle

3

(...) Meine anfängliche Hypothese war ungültig. Könnten Sie uns dann sagen, was die wahre Ursache war?

— Piotr Dobrogost

0

Soll die Uhr nicht eintönig sein, wenn sie nicht geändert wird? Rückwärtssprünge sollten nicht möglich sein. Es muss etwas sein, das die Uhr stellt - ein Cron-Job oder ein anderer Daemon (zum Beispiel ein Aufruf von hwclock --adjust). Ich erinnere mich, dass ntp selbst die Statistiken für Drift aktualisiert und routinemäßig kompensiert. Wenn Sie lange Zeit ntp nicht ausführen und einen großen Offset erhalten, wird die Zeit danach für Tage durcheinander gebracht, wenn Sie nicht zurücksetzen/etc/adjtime . Möglicherweise haben Sie so etwas eingerichtet - etwas, das die Zeitdrift periodisch neu anpasst (und Sprünge verursacht).

ntp soll diesem Problem eigentlich entgegenwirken.

— orion
quelle

Das habe ich auch gedacht. Meine Lektüre der Hardware-Taktquellen legt nahe, dass der Zähler monoton ansteigen sollte. Wenn das wahr wäre, sollten wir schlimmstenfalls unregelmäßige Tick-Raten beobachten, aber niemals zurückspringen. Ich verstehe, dass auf einem Multiprozessorsystem TSC zwischen den Prozessoren synchronisiert werden muss - vielleicht verursacht dies Rücksprünge?

— Brett