Timer: Zeitstempel erweitern

Steve van de Grens schrieb:

Irgendwo habe ich mal gelesen, dass Linux und Windows beide auch keine exakten Millisekunden kennen. Das sieht nur so aus, wenn man sich Logfiles anschaut.

Jein. Bei Linux kommt es auf Architektur und Konfiguration an. Bei i386 (und X86_64) wurde der Jiffie-Takt mal von 100 Hz auf 1000 Hz erhöht, aktuell kannst du tickless (mit HPET-Support, nsec-Auflösung) oder mit konfigurierbarem (Kernel-Compile-Time) Jiffie-Takt (100 Hz, 250 Hz, 300 Hz, 1000 Hz) arbeiten. ARM (um diese Architektur geht es hier ja) unterstützt ebenfalls HPET und tickless Kernel.

Worst-Case wäre also 100 Hz und damit eine Auflösung von 10msec. Bei meinem Debian-Kernel (x86) sind es 250 Hz und damit 4msec Auflösung.

Aber wenn du deinen Kern selbst baust, dann gibt es keinen Grund, warum du dort nicht auf 1000 Hz gehen kannst und somit für die Systemzeit (egal ob REALTIME oder MONOTONIC) echte Millisekunden-Auflösung bekommst.

Für Zeitmessungen, Timer etc. unterstützt ein System mit HPET aber wirklich nsec-Auflösung (64 bit) im Kernel, da hängt die Auflösung wirklich nur noch vom Systemtakt ab. Und bei GHz-Systemtakt bist du dann wirklich bei nsec-Auflösung.

Steve van de Grens schrieb:

Aber wie wird denn auf einem PC die RTC Zeit um diese Millisekunden ergänzt?

Die übliche RTC im PC ist so schlecht, dass sich das nicht lohnt. Was will ich mit Millisekunden, wenn die RTC nach einer Nacht um eine ganze Sekunde daneben liegt?

Beim Booten übernimmt der Linux-Kernel die RTC-Zeit mit 1 Sekunde Auflösung, die Milli-, Mikro- oder Nano-Sekunden sind erstmal Null. Danach wird die RTC nicht mehr benutzt -- außer, wenn die Kernel-Uhr vom ntpd synchronisiert wird. Dann stellt der Kernel die RTC alle 11 Minuten. Dabei wird Auflösung von der RTC-Hardware begrenzt, theoretisch 1/32768 Sekunde, praktisch z.B. 1/64 oder 1/8192 Sekunde.

In dem Moment geht die RTC normalerweise auf besser als 10ms genau, das schafft der ntpd auch über eine billige DSL-Verbindung. Im LAN oder per GPS kann der Fehler der Systemuhr auch auf wenige Mikrosekunden reduziert werden, aber die RTC schafft kaum einstellige Millisekunden.

Bei einer selbstgebauten Hardware mit ARM könnte man auch 100ns Auflösung und mit einem guten GPS-Empfänger unter 1µs Fehler haben. Aber eine RTC, die da mithalten kann, will man nicht bezahlen.

Schlaumaier schrieb:

Steve van de Grens schrieb:

Irgendwo habe ich mal gelesen, dass Linux und Windows beide auch keine exakten Millisekunden kennen.

Macht Sinn und wird auch NIE anders sein.

Ja ja, der Schlaumaier. Die Zeiten, in denen auf Intel-HW die 18Ticks/s das sagen hatten, sind eigentlich schon lange vorbei.

Immerhin dauert auch die Berechnung selbst einige MS. Ergo kann es

MegaSamples, MegaSiemens, ... aber Du meintest sicherlich ms, was aber auch falsch wäre - eher µs oder gar ns ... Heutezutage (naja, schon eher 2 Jahrzehnte oder so) tickt man eher im ns-Bereich, wenn es unbedingt sein muß. HPET wurde ja schon genannt. Wenn man bei irgendeiner einigermaßen modernen SW Traces ziehen läßt, kann man etliche Trace-Records pro µs fortlaufend sehen.

NIEMALS 100% genau sein.

Was ist schon 100%ig genau?

Schlaumaier schrieb:

Habt ihr Superhelden auch mal an das "möchte Gern Multitasking" von Windows gedacht. Allein schon bis der Prg. überhaupt berechtigt ist, die Zeit zu messen sind schon einige MS vergangen.

... schon wieder MegaSamples ... Aber die Timerwerte zu ermitteln geht ratzfatz - klar, auf seine Zeitscheibe muß der Prozess schon warten, wenn er gerade nicht dran ist. Aber das müssen dann nicht gezwungenermaßen ms sein, sondern können auch niedrige µs sein - wie bei jedem normalen Multitaskingsystem (Realtime OS (nicht "normale" Linuxe) sind zwar besser, können aber auch nichts garantieren, wenn entsprechend ausgelastet)

Zeitmessung im MS o. kleiner Bereich ist auf ein PC ohne externe Hardware eh nicht möglich. Das verhindert schon sehr wirkungsvoll das System.

bla bla ...

Ich hatte bei meiner Aussage eh mehr an Microcontroller gedacht, wo man

Nöö - Du hast Dich klar auf ein Windows-/Linux-spezifisches Statement bezogen.

Steve van de Grens schrieb:

Events nach Zeitstempel zu sortieren ist eh problematisch.

Kommt auf den Timestamp drauf an … ;-)

Ich habe gerade im Elastic Search mal wieder irritierende Logmeldungen gesehen, deren Reihenfolge durcheinander gebracht wurde, weil sie in der selben ms stattfanden. Da kommt dann manchmal die Fehlermeldung "no record found" vor der Meldung "loading customer with ID 12345".

Für solchen Kram hatte ich normalerweise einen Preprozessor, der die einzelnen Zeilen derartiger Messages zusammengesetzt hat bevor sie an ES verfüttert wurden. Gerade bei Fehlermeldungen von Datenbanken (PostgresQL in meinem Fall) war das extrem hilfreich.

Andererseits brauchen wir die Sortierung nach Zeitstempel, weil wir da Logmeldungen von zahlreichen PODs zusammen tragen.

rsyslogd mit Hires Timestamps liefert Mikrosekunden, da werden Verdrehungen schon erheblich unwahrscheinlicher. Im Zweifelsfall helfen Sequenznummern in den Messages (muss man halt selbst in seiner Software einbauen), um bei der Sortierung der Zeilen die Reihenfolge beizubehalten.