Thema: Wofür hab Ihr bisher den TSC benutzt?

[erik.vikinger]

Hallo,


meine Frage steht ja schon im Betreff. Es geht mir darum mal einen Überblick zu bekommen wofür so alles der TSC (bei x86) benutzt wird.
Dazu dann gleich noch die Frage ob Ihr mit dem TSC auch zufrieden wart oder ob Ihr lieber was anderes benutzt hättet, z.B. den HPET, bzw. welche Ansprüche Ihr an eine gute Zeitquelle stellt.


Mir ist nämlich aufgefallen das ich sowas wie den TSC bei meiner CPU gar nicht habe und wollte einfach mal wissen ob man sowas überhaupt wirklich benötigt oder ob nicht ein guter HPET auch ausreicht. Einen guten HPET möchte ich schon implementieren. Das Problem was ich beim HPET sehe ist das dieser im Chipsatz (oder einer anderen zentralen Stelle) ist und ein Lesezugriff immer locker über 100 CPU-Takte kostet wogegen der RDTSC-Befehl fast gar nichts kostet. Des weiteren ist der HPET eine System-Ressource die gar nicht so einfach von normalen User-Mode-Programmen benutzt werden kann wogegen der TSC eigentlich jedem Programm zur Verfügung steht (ich glaube nicht das es überhaupt ein OS gibt das den RDTSC-Befehl für den User-Mode abschaltet). Zusätzlich hat der TSC eine höhere zeitliche Auflösung wobei man sich da auch fragen muss wozu man irgendetwas genauer als auf 100 ns (was ein HPET mit 10MHz bietet) timen können muss. Der große Nachteil des TSC ist natürlich das er keine Interrupts generiert und das es mehrere unabhängige davon gibt die auch auseinander driften können. Also für echtes Timing ist der TSC damit wohl sowieso nicht qualifiziert oder seit Ihr da anderer Meinung? Wenn ja Warum?


Wie hoch seht Ihr allgemein den Bedarf an einer streng monotonen Zeitquelle in einem OS?
Wie genau sollte die sein?
Sollte sich so eine Zeitquelle von der Sommerzeit/Winterzeit-Umstellung oder von Schaltsekunden beeinflussen lassen?


Grüße
Erik

[Svenska]

Wie hoch seht Ihr allgemein den Bedarf an einer streng monotonen Zeitquelle in einem OS?
Wie genau sollte die sein?

Sie muss in jedem Fall vorhanden sein und zwar mit hinreichend hoher Auflösung.

Denn wenn du z.B. "make" aufrufst, dann vergleicht der Datum und Uhrzeit der letzten Änderung von Quelldateien und Zieldateien; ist die Quelle neuer (oder gleich neu) als das Ziel, wird neu gebaut. Wenn du parallel baust und deine Bezugszeitquelle nicht monoton ist (oder das Dateisystem keine hinreichende Auflösung hat), fliegt dir das um die Ohren.

Das passiert, wenn man auf FAT Programme baut und das kompilieren der Einheit unter zwei Sekunden dauert. Dann wird immer kompiliert, was schlecht ist.

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.

my 0,02€$

Gruß,
Svenska

[kevin]

rdtsc habe ich bisher nur mal benutzt, um den Overhead von Syscalls zu messen und zu optimieren.

Aber was Zeitmessung angeht, ist tyndur sowieso steinzeitlich - wir benutzen normal nur den PIT.

[FlashBurn]

Ich nutze den TSC zum messen der CPU Frequenz (obwohl das auch bei neueren CPUs eher schwierig bis unmöglich wird) 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.

Ansonsten ist eine monotone Zeitquelle Pflicht!

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).

[erik.vikinger]

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

[kevin]

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.

Erstens das, aber vor allem zweitens, dass man dafür nichts aufsetzen muss, sondern einfach die Zeit auslesen kann, und drittens, dass es auch im Userspace tut.

[erik.vikinger]

Hallo,

aber vor allem zweitens, dass man dafür nichts aufsetzen muss, sondern einfach die Zeit auslesen kann

Stimmt, daran hatte ich noch gar nicht explizit gedacht. Das ist aber ein genereller Vorteil simpler monotoner Counter mit großer Bitbreite die eben einfach so vor sich hin zählen und sich durch nichts beeinflussen lassen.

und drittens, dass es auch im Userspace tut

Ja, das ist durchaus ein wichtiges Argument, wenn man dafür immer extra einen Syscall machen müsste wär das schon ziemlich doof (selbst dann wenn der Syscall einen extrem geringen Overhead hat).


Grüße
Erik