Hallo,
Erst mal Danke für Eure Antworten.
Sie muss in jedem Fall vorhanden sein und zwar mit hinreichend hoher Auflösung.
Gut, das ist soweit sicher konsensfähig. Bleibt nur noch zu klären was unter "
hinreichend" zu verstehen ist.
Ich habe vor meinen HW-Timer mit 16'000'000 Hz laufen zu lassen, ich denke das sollte hinreichend genug sein (vor allem wenn die CPUs erstmal kaum über 50 MHz hinaus kommen). Ich hab auch schon oft darüber nachgedacht den HW-Timer mit 16'777'216 Hz zu betreiben, das würde einige Vorteile beim Umrechnen in Sekunden gäben aber aus dieser Frequenz kommt man nur ganz schwer auf den Basis-Takt von den verschiedenen anderen HW-Komponenten (PCI-Express, USB, SATA, Audio-Samplerate, Bild-Wiederholrate ....) was auch wieder echt doof ist. 2 unabhängige Quarze möchte ich auch nicht haben, da müsste ich dann überall genau aufpassen aus welcher Frequenz was abgeleitet wird.
Sollte sich so eine Zeitquelle von der Sommerzeit/Winterzeit-Umstellung oder von Schaltsekunden beeinflussen lassen?
Nein.
Zeitzonen sind Sache des Betriebssystems. Die vernünftige Lösung ist, die Systemuhr in UTC zu haben und daraus die lokale Zeit zu generieren (Unix). Wenn die Systemuhr Lokalzeit anzeigt, werden Berechnungen über Zeitzonen hinweg schwierig.
Als monotone Zeitquelle fällt UTC aber auch wieder aus. Zwischen den Zeitpunkten "2008-12-31 12:00:00 UTC" und "2009-01-01 12:00:00 UTC" sind 86401 Sekunden vergangen und nicht 86400 wie sonst so üblich, es gab da die Sekunde "2008-12-31 23:59:60 UTC" als eine Schaltsekunde eingefügt wurde.
Als monotone Zeitquelle in einem Computer taugt IMHO nur ein simpler Counter der stur mit einer festen und möglichst präzisen Frequenz nach oben zählt und mit der ersten Stromzufuhr bei 0 startet. So ein Counter sollte auch weiterlaufen wenn der Computer Suspend to RAM oder gar Suspend to Disk macht damit die laufenden (eingefrorenen) Programme da nicht durcheinander kommen. Alles weitere ist meiner persönlichen Meinung nach Aufgabe eines Zeit-Dämons, dieser müsste erstmal den exakten Zeitpunkt bestimmen (errechnen) als der HW-Counter bei 0 angefangen hat und kann von da an auf Basis dieses Counters immer nach UTC oder sonstwas umrechnen. Ein weiterer wichtiger Punkt ist die Breite in Bit die dieser Counter haben muss, er sollte jedenfalls nicht in absehbarer Zeit überlaufen können. 64 Bit bei 16 MHz ergibt eine Laufzeit von über 34'865 Jahren und das sollte erstmal reichen damit eventuelle Regressansprüche nicht mehr mich persönlich treffen.
my 0,02€$
Genau darum hatte ich ja auch gebeten.
rdtsc habe ich bisher nur mal benutzt, um den Overhead von Syscalls zu messen und zu optimieren.
Aha, sicher weil er so schön schnell zählt und deswegen eine hohe zeitliche Auflösung bietet. Genau für solche Zwecke ist der TSC auch meiner Meinung nach sehr gut geeignet, vor allem weil es in einem x86-PC an verlässlichen und standardisierten Alternativen mangelt.
Aber was Zeitmessung angeht, ist tyndur sowieso steinzeitlich - wir benutzen normal nur den PIT.
Also mit solchen Sätzen werden ihr niemals Marktführer bei Betriebssystemen werden. Das muss anders lauten: Für das verlässliche und präzise Timing setzt tyndur auf langjährig erprobte und bewährte Technologien!
Ich nutze den TSC zum messen der CPU Frequenz (obwohl das auch bei neueren CPUs eher schwierig bis unmöglich wird)
Hm, das hatte ich bei einem Pentium 1 auch mal gemacht um ihn dann als Zeitbasis fürs Timing zu benutzen, damals war der TSC noch wirklich monoton aber bei heutigen CPUs ist der TSC eben nicht mehr monoton oder er hat nichts mehr mit der tatsächlichen Arbeitsfrequenz der CPU zu tun (das letzte ist laut Intel das zukünftige Standardverhalten bei allen Intel-CPUs und AMD wird da sicher mitziehen).
und ansonsten wird er eigentlich zum Messen von ganz kurzen Zeiten (z.B. nur ein paar Instruktionen bis mehrere tausend Instruktionen) genutzt, um, wie taljeth schon sagte, Code zu optimieren.
Das Problem was ich sehe ist das es mehrere TSCs gibt, zumindest bei mehreren Sockeln, und damit er von User-Mode-SW genutzt werden kann muss diese quasi auf eine bestimmte CPU festgepinnt werden was auch nicht immer praktikabel ist.
Ansonsten ist eine monotone Zeitquelle Pflicht!
Klar, in die Zeiten alter Amigas die teilweise noch keine HW-Uhr hatten und immer am 1.1.1970 booteten möchte wohl keiner mehr zurück.
Die Auflösung würde ich von der CPU abhängig machen, sprich wenn die Auflösung so hoch ist, das mehrere Ticks innerhalb einer Instruktion vergehen ist es eindeutig zu hoch. So 1µs ist wahrscheinlich für so ziemlich alle Sachen ausreichend. Dann kommt natürlich noch der Overhead zum Auslesen und Schreiben dazu. Dieser sollte auch wieder nicht größer als ein Tick sein (obwohl das bei einer Auflösung von 1µs auch nicht das Problem sein sollte).
Ja, klingt vernünftig. Wegen des schnellen Auslesens könnte ich in jeder CPU einen Sekundär-Counter vorsehen der immer exakt zum Basis-Counter synchron läuft, mit einer Tolleranz von 1 oder 2 ns aber eben
ohne Drift. Dann fehlt eigentlich nur noch ein Weg diesen Counter auch der User-Mode-SW anzubieten und ich denke da werde ich nicht um einen extra Befehl drum herum kommen.
Grüße
Erik
Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken