Schaltsekunde Linux
- Ersteller daiv
- Erstellt am
bofh_hannibal
THE BOFH
Man könnte meinen das Linux nicht richtig Tickt.
oder:
BSD ist immer einen Tick besser als Linux.
Prost !
oder:
BSD ist immer einen Tick besser als Linux.
Prost !
hades
the unseen one
Es ist lustig, eine Bekannte, in deren Institut mit SuSE-Linux gearbeitet wird, beschwert sich seit Montag, dass alle Rechner fürchterlich langsam seien... Nur dürfen diese von den Nutzern wohl nicht neugestartet werden.
Möglicherweise haben die auch ein Schaltsekundenproblem.
Möglicherweise haben die auch ein Schaltsekundenproblem.
christian83
Well-Known Member
Ich verstehe ehrlich gesagt nicht wo das Problem beim umstellen der Uhrzeit ist... Was genau ist bei dieser Zeitumstellung jetzt ein Problem und warum klappt es ohne Probleme wenn ich die Uhrzeit bei meinem Rechner selbst um eine Sekunde verstelle?
Bin ich zu blöd das Problem zu verstehen?
Grüße
Bin ich zu blöd das Problem zu verstehen?
Grüße
lockdoc
Well-Known Member
Hier steht bissel was darueber
http://www.heise.de/newsticker/meldung/Schaltsekunden-Bug-in-Linux-verschwendet-Strom-1631325.html
http://www.heise.de/newsticker/meldung/Schaltsekunden-Bug-in-Linux-verschwendet-Strom-1631325.html
Das ist eine klassische Regression. Man kann nun lästern (und nichts täte ich lieber), auf die noch immer noch sehr unzureichende Test-Abdeckung des Linux-Kernels hinweisen (die BSDs sind nicht deutlich besser) und so weiter... Aber andererseits passieren solche Dinge halt. Das einzig Interessante ist die unterschiedliche Weltwahrnehmung im Heise-Forum. Nun wird suggeriert, dass es ja gar nicht so schlimm war. Aber wehe, Windows hätte einen solchen Bug! 
Illuminatus
in geheimer Mission
ohne jetzt Links aus den letzten Jahren zu suchen, in denen Bugs bzgl. Schaltsekunden und Zeitzonenanpassungen...
ich erinnere mich dass es schon früher Probleme und echte Abstürzen in die News geschafft hatten. Ebenfalls meine ich, dass schon iPhone Benutzer in Russland nichts von der letzten Sommerzeit Direktive mitbekommen haben und der Wecker die Nutzer hat weiter schlummern lassen.
Gerüchten zufolge sol die x86 Architektur nicht gerade berühmt sein für präzise Timer.
Und dass HPET bzw tsc von Virtualisierern eine saubere Zeit in VMs reichen ist auch noch recht jung. Leider mache ich nur selten etwas mit zeitkritischen Anwendungen. Andere hier können sicherlich mehr dazu sagen, und gute Setups beim Namen nennen. Vor allem in Bezug auf VoIP.
Möchte jemand Best Practice auflisten, ausgenommen eine Downtime zu planen wenn die Zeit mal wieder geändert wird?
ich erinnere mich dass es schon früher Probleme und echte Abstürzen in die News geschafft hatten. Ebenfalls meine ich, dass schon iPhone Benutzer in Russland nichts von der letzten Sommerzeit Direktive mitbekommen haben und der Wecker die Nutzer hat weiter schlummern lassen.
Gerüchten zufolge sol die x86 Architektur nicht gerade berühmt sein für präzise Timer.
Und dass HPET bzw tsc von Virtualisierern eine saubere Zeit in VMs reichen ist auch noch recht jung. Leider mache ich nur selten etwas mit zeitkritischen Anwendungen. Andere hier können sicherlich mehr dazu sagen, und gute Setups beim Namen nennen. Vor allem in Bezug auf VoIP.
Möchte jemand Best Practice auflisten, ausgenommen eine Downtime zu planen wenn die Zeit mal wieder geändert wird?
Was ich nicht verstehe ist, warum die Zeit überhaupt verändert wird.
Man hat doch die Unix Zeit, damit sollte stoisch die Zeit seit dem Beginn der Zeitrechnung
gezählt werden. Alle Korrekturen sollten meiner Meinung nach nur als Offset bei der Darstellung draufgerechnet werden.
Man hat doch die Unix Zeit, damit sollte stoisch die Zeit seit dem Beginn der Zeitrechnung
gezählt werden. Alle Korrekturen sollten meiner Meinung nach nur als Offset bei der Darstellung draufgerechnet werden.
Die einzelnen Betriebssysteme funktionieren dort recht unterschiedlich. FreeBSD hat den Vorteil, dass Poul-Henning Kamp ein "Time-Keeping Nerd" ist und entsprechend viel Arbeit in die interne Zeitmessung gesteckt hat... Das grundlegende Prinzip aller oder zumindest der meisten Betriebssysteme ist aber:
1. Lese beim Boot die Zeit aus der CMOS-Uhr und wandele sie in ein internes Format um. Dies interne Format ist meist einfach ein lineares Offset eines definierten Zeitpunkts. Unter Unix halt Sekunden seit 1.1.1970 00:00, Windows nutzt meines Wissens ein Datum irgendwann Ende 1992. Wichtig ist, dass die Zählung keinerlei Abweichungen beinhaltet, Dinge wie Schaltjahre, Schaltsekunden und ähnliches werden dabei nicht beachtet.
2. Mittels der internen Zeitzähler der CPU wird die Zeit zur Laufzeit monoton erhöht. Die Dinger sind ein Thema für sich und generell nicht wahnsinnig genau, aber meist genau genug. Dienste wie NTP passen die Geschwindigkeit dieser Zeitzähler an, sie lassen die Uhr also gezielt langsamer oder schneller laufen und halten sie so nahe der korrekten Einstellung. Dadurch ist ein direktes setzen nicht nötig, es gibt also keine Zeitsprünge. Diese Zeitangaben werden regelmäßig in die CMOS-Uhr zurückgeschrieben, sodass die Abweichung nicht bei jedem Boot komplett neu ausgeglichen werden muss.
3. Wird eine Zeit angefragt, z.b. per gettimeofday() wird die interne Zeit mittels einer Zeitzonendefinition in absolute Zeit umgerechnet. Unter FreeBSD wird diese Definition von adjkernz(8) in den Kernel geladen, andere Systeme haben ähnliche Mechanismen. An diesem Punkt scheiterte es unter Linux an einem klassischen Deadlock.
Der Deadlock war grob:
1. Neue Zeitzonendefintion wird geschrieben, also eine Sekunde eingefügt.
2. Der Zeit-Handler möchte dies ins Log schreiben, muss den Log-Service starten.
3. Der Log-Service muss sich die Zeit holen, um die Zeitangabe zu generieren.
4. Er kann aber keine Zeit bekommen, solange die neue Zeitzonendefinition nicht vollständig geschrieben ist, da bis dahin ein Lock auf ihr liegt. Dies ist aber erst der Fall, wenn das Ereignis ins Systemprotokoll geschrieben wurde.
=> der Log-Dienst wartet ewig auf die Zeit, der Zeit-Handler ewig auf den Erfolg die Rückkehr des Log-Dienstes.
EDIT sagt zur Quelle: http://www.heise.de/open/news/foren/S-Warum-es-passiert/forum-232244/msg-22050683/read/
1. Lese beim Boot die Zeit aus der CMOS-Uhr und wandele sie in ein internes Format um. Dies interne Format ist meist einfach ein lineares Offset eines definierten Zeitpunkts. Unter Unix halt Sekunden seit 1.1.1970 00:00, Windows nutzt meines Wissens ein Datum irgendwann Ende 1992. Wichtig ist, dass die Zählung keinerlei Abweichungen beinhaltet, Dinge wie Schaltjahre, Schaltsekunden und ähnliches werden dabei nicht beachtet.
2. Mittels der internen Zeitzähler der CPU wird die Zeit zur Laufzeit monoton erhöht. Die Dinger sind ein Thema für sich und generell nicht wahnsinnig genau, aber meist genau genug. Dienste wie NTP passen die Geschwindigkeit dieser Zeitzähler an, sie lassen die Uhr also gezielt langsamer oder schneller laufen und halten sie so nahe der korrekten Einstellung. Dadurch ist ein direktes setzen nicht nötig, es gibt also keine Zeitsprünge. Diese Zeitangaben werden regelmäßig in die CMOS-Uhr zurückgeschrieben, sodass die Abweichung nicht bei jedem Boot komplett neu ausgeglichen werden muss.
3. Wird eine Zeit angefragt, z.b. per gettimeofday() wird die interne Zeit mittels einer Zeitzonendefinition in absolute Zeit umgerechnet. Unter FreeBSD wird diese Definition von adjkernz(8) in den Kernel geladen, andere Systeme haben ähnliche Mechanismen. An diesem Punkt scheiterte es unter Linux an einem klassischen Deadlock.
Der Deadlock war grob:
1. Neue Zeitzonendefintion wird geschrieben, also eine Sekunde eingefügt.
2. Der Zeit-Handler möchte dies ins Log schreiben, muss den Log-Service starten.
3. Der Log-Service muss sich die Zeit holen, um die Zeitangabe zu generieren.
4. Er kann aber keine Zeit bekommen, solange die neue Zeitzonendefinition nicht vollständig geschrieben ist, da bis dahin ein Lock auf ihr liegt. Dies ist aber erst der Fall, wenn das Ereignis ins Systemprotokoll geschrieben wurde.
=> der Log-Dienst wartet ewig auf die Zeit, der Zeit-Handler ewig auf den Erfolg die Rückkehr des Log-Dienstes.
EDIT sagt zur Quelle: http://www.heise.de/open/news/foren/S-Warum-es-passiert/forum-232244/msg-22050683/read/