Extremer Lag 3,5 Minuten nach dem Booten unter RT-Linux

hääää schrieb:
> Rolf F. schrieb:
>> ...3,5 Minuten nach dem Booten...
>>
> schon mal cron-jobs und ähnlichem nachgesehen?

Bei Cron-Jobs würde das Problem regelmäßig auftauchen, nicht nur einmal 
nach dem Booten.

Ich würde mal nach der Ausgabe von

journalctl -b

sehen.

Erwin M. schrieb:
> Bei Cron-Jobs würde das Problem regelmäßig auftauchen, nicht nur einmal
> nach dem Booten.
>
nicht unbedingt --> anacron u.ä.

Grüße Uwe

Kann auch am Rechner liegen, z.B. wenn der im Hintergund über einen SMI 
irgendeinen Work-Around für einen Hardware-Bug ausführt.
Das sieht nach einer ganz guten Liste typischer Gründe aus:
https://rt.wiki.kernel.org/index.php/HOWTO:_Build_an_RT-application

> Wenn das ding 3min lang hängt, würde ich einfach mal den Debugger dran
> hängen und schauen was er in dem Moment macht.

Hängt von der Anzahl der Cores ab. Wenn es nur einen gibt, ist keine CPU 
für den Debugger frei ;)

Eine andere Möglichkeit wäre noch strace. Interessant wäre auch, ob der 
Rest des Systems da klemmt, sieht man zB. an einem flood-ping. Evtl. 
gibts auch noch was in dmesg zu sehen. Wenn der Hänger reproduzierbar 
ist (klingt so), sehe ich kein grösseres Problem, die Ursache zu 
finden...

Peter II schrieb:

> Wenn das ding 3min lang hängt, würde ich einfach mal den Debugger dran
> hängen und schauen was er in dem Moment macht.

Der hängt nicht für 3 Minuten sondern 3,5 Minuten nach dem Booten 
geschieht das Lag von 0,3 s.

Anacron ist auf dem Rechner nicht installiert.

Mit

systemctl -b

wurde auch klar wieso das Lag auftritt:


  Aug 26 12:17:29 messrechner systemd[1]: Time has been changed

Das ist wohl der ntp.
Damit ist auch klar das es kein tatsächliches Lag ist sondern nur die 
Anpassung der Systemzeit.
Angeblich macht ntp das nur mit jeweils wenigen µs Änderung, aber das 
ist hier nicht der Fall.
Aber für das Programm ist das kein Problem, da auf andere Uhren als 
CLOCK_REALTIME gewechset werden könnte und die Aktivitätszeitpunkte ja 
in jedem Fall im 33 µs-Raster vorhanden sind.

Du könntest ja inital beim Booten mit ntpdate die Zeit setzen. Dann 
sollte danach eigentlich kein Sprung mehr auftauchen.

Aber diese Time-Daemons mit ihren obskuren Pseudo-PLLs sind eh alle des 
Teufels. Wir haben PTP zu Erreichung von us-Genauigkeit im Netz 
ausprobiert (braucht auch PTP-fähige Netzwerkchips). Ging super, lief 
über Tage hinweg gut. Und dann macht ein ptpd spontan einen Sprung von 
36 Stunden VORWÄRTS :-O . Dann lieber wieder nur ntpd.

Georg A. schrieb:
> Wir haben PTP zu Erreichung von us-Genauigkeit im Netz
> ausprobiert (braucht auch PTP-fähige Netzwerkchips).

Es geht auch ohne spezielle Netzwerkkarten; dann wird software 
timestamping statt hardware timestamping verwendet:

http://linuxptp.sourceforge.net/

> Es geht auch ohne spezielle Netzwerkkarten;

Was aber die Genauigkeit wieder verschlechtert. Wir wollten bei dem Test 
schon so gut wie möglich sein. Und e1000-Karten bzw. Boards damit sind 
inzwischen auch nicht mehr so teuer.

> Kommt ganz darauf an, woher ihr die Zeit bezieht.

Ein Rechner war die Masterclock, da hat sich nichts geändert. Die 
Sprünge sind öfters aufgetreten, immer bei anderen Rechnern, nie auf 
allen gleichzeitig... Es ging da auch nicht um absolut genaue 
(Atom)Zeit, sondern um die Synchronität aller Rechner im Netz (war eine 
Messaufgabe mit zu Anfang nicht genau definierbaren 
Genauigkeitsanforderungen).

Georg A. schrieb:
> Du könntest ja inital beim Booten mit ntpdate die Zeit setzen. Dann
> sollte danach eigentlich kein Sprung mehr auftauchen.

Eigentlich sollte es genau umgekehrt sein. ntpd sollte keine Sprünge in 
der Uhr auslösen, sondern nur deren Geschwindigkeit anpassen, um sie zur 
richtigen Zeit "hinzuziehen". Das dauert zwar länger, aber vermeidet 
eben die Sprünge, die nicht nur an der Stelle problematisch sind.

> Eigentlich sollte es genau umgekehrt sein. ntpd sollte keine Sprünge in
> der Uhr auslösen, sondern nur deren Geschwindigkeit anpassen, um sie zur
> richtigen Zeit "hinzuziehen". Das dauert zwar länger, aber vermeidet
> eben die Sprünge, die nicht nur an der Stelle problematisch sind.

Es gibt da aber als Default die Grenze von 1000s, bis zu der noch 
gezogen wird. Ist halt die Frage, wie daneben das jetzt ist. Dass das 
erst nach 3min passiert, ist jedenfalls klar. ntpd misst ja erstmal die 
Abweichungen...

Rolf M. schrieb:
> Eigentlich sollte es genau umgekehrt sein. ntpd sollte keine Sprünge in
> der Uhr auslösen, sondern nur deren Geschwindigkeit anpassen, um sie zur
> richtigen Zeit "hinzuziehen". Das dauert zwar länger, aber vermeidet
> eben die Sprünge, die nicht nur an der Stelle problematisch sind.

Ja, nur ist es eine philosophische Frage was die richtige Zeit ist. Und 
bei der Unix-Definition, auf der auch MS-Windows und Linux aufbauen, 
fehlen schon die Schaltsekunden, aber zum Protokollieren will man die 
normalerweise haben, weil die in der gesetztlichen Zeit enthalten sind.

oszi40 schrieb:
> Rolf M. schrieb:
>> ntpd sollte keine Sprünge
>
> Falls z.B. die Zeitzone od. DNS sich ändert, wären auch etwas kuriose
> Effekte möglich? Kommt selten vor, wäre so meine letzte Idee wo man mal
> nachsehen könnte.

Laut der Dokumentation von ntp benötigt man die Option "tinker step 0", 
damit nicht gesprungen wird.
Das probiere ich aus.

>Extremer Lag 3,5 Minuten nach dem Booten unter RT-Linux

Wie hat denn der Extreme das Liegen unter dem RT-Linux verkraftet?

Fragt sich
-Paul-

Paul B. schrieb:
> Wie hat denn der Extreme das Liegen unter dem RT-Linux verkraftet?

https://www.youtube.com/watch?v=MOs4vsthLD0

> Laut der Dokumentation von ntp benötigt man die Option "tinker step 0",
> damit nicht gesprungen wird.
> Das probiere ich aus.

Schau doch mal, was die Zeitdifferenz nach dem Booten ohne ntpd ist. 
"ntpdate -d" gibt die aus, ohne was zu drehen. Meine 1000s von oben 
waren eh falsch erinnert (die sind der Panic threshold), bei meinem ntpd 
steht bei Option -x:

Normally,  the  time  is slewed if the offset is less than the step 
threshold, which is 128 ms by default, and stepped if above the 
threshold.

Damit wird es recht wahrscheinlich, dass die Zeit nach dem Booten 
springt, so toll sind die RTCs auch nicht. Ich verstehe aber nicht, wo 
das Problem liegt, während des Bootens die Zeit mit ntpdate hart zu 
setzen. Dann muss man auch später nicht so an der Zeit rumziehen. AFAIR 
kann man das in einigen Startupskripts auch einstelleen.

Georg A. schrieb:
> Ich verstehe aber nicht, wo
> das Problem liegt, während des Bootens die Zeit mit ntpdate hart zu
> setzen. Dann muss man auch später nicht so an der Zeit rumziehen.

Das geht nicht so leicht, denn das Messprogram wird als Systemd-Service 
gestartet, auch damit es automatisch neu gestartet wird wenn es vor dem 
Shutdown terminiert.
Und wenn der Rechner mal ein Jahr ununterbrochen läuft, dann verschiebt 
sich die RTC deutlich.

> Das geht nicht so leicht, denn das Messprogram wird als Systemd-Service
> gestartet,

Dann startet man ntpdate halt vorher ;) Oder kann der ominöse systemd 
keine Reihenfolge...

Georg A. schrieb:
>> Das geht nicht so leicht, denn das Messprogram wird als Systemd-Service
>> gestartet,
>
> Dann startet man ntpdate halt vorher ;) Oder kann der ominöse systemd
> keine Reihenfolge...

Der Rechner soll ständig messen und nicht auf irgendwas warten.
Und seit ich tinker step 0 verwende ist das Problem nicht mehr 
aufgetaucht.

> Der Rechner soll ständig messen und nicht auf irgendwas warten.

Wenn er bootet, misst er sicherlich nicht ;) Das ntpdate während des 
Bootens kostet evtl. so 4s. Es geht nur um den initialen Setup-Vorgang 
der Systemzeit während des Bootens. Danach hat der ntpd auch keine 
Veranlassung mehr, Zeitsprünge zu machen.

> Und seit ich tinker step 0 verwende ist das Problem nicht mehr
> aufgetaucht.

Ist halt keine vernünftige Lösung, weil die Zeit deiner Messungen dann 
über die ganze Fehlzeit hinweg verbogen wird.

Georg A. schrieb:
>> Der Rechner soll ständig messen und nicht auf irgendwas warten.
>
> Wenn er bootet, misst er sicherlich nicht ;) Das ntpdate während des
> Bootens kostet evtl. so 4s. Es geht nur um den initialen Setup-Vorgang
> der Systemzeit während des Bootens. Danach hat der ntpd auch keine
> Veranlassung mehr, Zeitsprünge zu machen.

Ja, nur das Problem bei dem einen Messrechner ist das der an der 
Stromversorgung der Maschine hängt und die wird mal ein- oder 
ausgeschaltet, beispielsweise über Nacht, so das sich auch mit USV nicht 
vermeiden lässt den Rechner runterzufahren und neu zu Booten.
Um möglichst wenig zu verpassen soll nicht auf ntp gewartet werden.


>> Und seit ich tinker step 0 verwende ist das Problem nicht mehr
>> aufgetaucht.
>
> Ist halt keine vernünftige Lösung, weil die Zeit deiner Messungen dann
> über die ganze Fehlzeit hinweg verbogen wird.

Das macht der NTP sowieso; ich stelle nur die Zeitsprünge ab.
Das Verbiegen lässt sich nicht vermeiden, weil die Systemzeit ohne 
Schaltsekunden ist und die Uhr driftet.

> Das Verbiegen lässt sich nicht vermeiden, weil die Systemzeit ohne
> Schaltsekunden ist und die Uhr driftet.

Ja, es ist aber ein Unterschied ob der ntp über lange Zeit den 
Initialfehler von ein paar Sekunden hinbiegen muss oder nur die eher 
kleine und vor allem recht konstante Drift des Systemoszillators. Ich 
mein ja nur, wenn du schon alle 33us misst ;)

Georg A. schrieb:
>> Das Verbiegen lässt sich nicht vermeiden, weil die Systemzeit ohne
>> Schaltsekunden ist und die Uhr driftet.
>
> Ja, es ist aber ein Unterschied ob der ntp über lange Zeit den
> Initialfehler von ein paar Sekunden hinbiegen muss oder nur die eher
> kleine und vor allem recht konstante Drift des Systemoszillators.

Das ist nur ein kleiner Unterschied, maximal 500 ppm.
Das heißt gemessen wird mit einem Intervall von 33,0165 bis 32,9835 µs.
Zum Synchronisieren mit einem anderen Rechner bräuchte man generell ein 
Taktsignal mit doppelter Periodendauer, damit man auf 33 µs genau 
synchron ist, auch kurz nach einer Schaltsekunde.