Nachdem ich ein Messprogramm erfolgreich getestet habe, habe ich es als Systemd-Service eingerichtet, so das es beim Booten automatisch gestartet wird. Aber nun zeigt sich das das Einlesen alle 33 µs zu um 70 % genau einmal gestört wird und zwar um 3,5 Minuten nach dem Booten wird es verzögert/angehalten und zwar um 300000 µs, also extrem! Bisher zeigte sich, später nach dem Booten, nur eine Verzögerung von maximal 30 µs während 10 Tagen Messung, also nur nur ein zehntausendstel und typisch für einen RT-Kernel. Den aktuellen habe ich aus den Quellen und dem RT-Patch von kernel.org erstellt. Was kann die Ursache sein? Verdächtige wie Einträge in Boot-Skripten und Kernel-Meldungen (dmesg) scheiden aus weil sie vor den 3,5 Minuten liegen. Und zu dem Zeitpunkt ist noch kein User eingeloggt. Der Rechner läuft unter Ubuntu Server, ohne GUI, mit wenig laufenden Programmen und auch wenig Kernel-Modulen, da ich überflüssiges wie Bluetooth auf die Blacklist gesetzt habe.
Rolf F. schrieb: > Aber nun zeigt sich das das Einlesen alle 33 µs zu um 70 % genau einmal > gestört wird und zwar um 3,5 Minuten nach dem Booten wird es > verzögert/angehalten und zwar um 300000 µs, also extrem! > Bisher zeigte sich, später nach dem Booten, nur eine Verzögerung von > maximal 30 µs während 10 Tagen Messung, also nur nur ein zehntausendstel > und typisch für einen RT-Kernel. > du wolltest was mit diesem Wortirrgarten sagen?
Rolf F. schrieb: > ...3,5 Minuten nach dem Booten... > schon mal cron-jobs und ähnlichem nachgesehen?
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
Rolf F. schrieb: > Systemd-Service eingerichtet, so das es beim Booten automatisch > gestartet wird. Man muß ja nicht jeden Mist sofort starten. http://www.linuxwiki.de/crontab
oszi40 schrieb: > Man muß ja nicht jeden Mist sofort starten. > http://www.linuxwiki.de/crontab eine Prozess der dauernd laufen soll, als crontab? 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.
> 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.
:
Bearbeitet durch User
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/
Georg A. schrieb: > Und dann macht ein ptpd spontan einen Sprung von > 36 Stunden VORWÄRTS :-O . Dann lieber wieder nur ntpd. Kommt ganz darauf an, woher ihr die Zeit bezieht. Wenn die Zeit evtl. von einem kaputten Impulstelegramm des DCF77 gespeist wird, kann er noch viel mehr Unsinn anrichten. Wahrscheinlich wird totz Precision Time Protocol (PTP) ungenügend auf Plausibilität der Werte geprüft?
> 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.
Evtl. steckt ein simpler SW-Fehler dahinter. Schon verschiedene MS+Linux-Systeme als Gegenprobe getestet? Gab es verdächtige Einträege in Logfiles? 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.
> 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.
Ich empfehle ftrace: http://lwn.net/Articles/410200/ Event 'sched:*' aufzeichnen (trace-cmd -e 'sched:*' start oder so) Nach 3,5min+epsilon mit "trace-cmd stop" die Ereignisse der letzten paar Sekunden rausschreiben lassen, mit kernelshark die trace.dat angucken, und da sollte dann zu sehen sein, wie die Prozesse geschedult wurden. Es gibt auch noch andere Events, die man mit aufzeichnen kann, etwa Netzverkehr, Interrupts.
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.
Wenn ich das alles so lese, würde ich erst mal eine simple Gegenprobe mit einem anderem Rechner als NTP machen, da das Übel ja auf einigen Geräten auftrat.
>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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.