GetTickCount für Linux?
-
Hallo zusammen.
Ich versuche derzeit GetTickCount aus der Windows-API für Linux zu erreichen (relative Zeit in Millisekunden). Bisher habe ich nur 'times' und 'clock' gefunden, welche aber leider nur einen Abstand von 72 Minuten zwischen zwei Overflows haben, was für mich zu schnell ist (liegt daran, dass Ergebnis Mikrosekunden statt Millisekunden ist). Kennt jemand eine ähnliche Funktion, die Millisekunden zurückgibt (max. 49.7 Tage)?
Grüße,
Neku
-
Hallo,
Die Funktion gettimeofday liefert Dir Mikrosekunden ganz ohne Überlauf
Ich benutze immer folgende Funktion wenn ich Zeitmessungen machen will (ohne mit den zwei Membern der timeval struct hantieren zu müssen):
uint64_t getTimeMs(void) { struct timeval tv; gettimeofday(&tv, 0); return uint64_t( tv.tv_sec ) * 1000 + tv.tv_usec / 1000; }
-
Kommt leider auch nicht in Frage, da die Funktion abhängig der Systemzeit ist und das Programm ins verderben rennt, sobald diese sich ändert
-
hä inwievern ?
-
Er meint da gettimeofday einen Zeitpunktabhängigen Stempel liefert, kannst Du Messungen manipulieren, indem Du den Startzeitpunkt festhälst, die Uhr 10 Minuten zurück drehst und dann die Stoppzeit festhälst. Das Programm wäre jetzt -10 Minuten gelaufen...
Mit einem Clockstempel (Anzahl irgendeines Taktes seit Systemstart) kann man das nicht.
-
Gerade scharmlos geklaut und nicht getestet, aber vielleicht hilfreich
#include <sys/sysinfo.h> long getTickCount() // Zeit seit dem Booten in Sekunden { struct sysinfo si; if(sysinfo(&si) == 0) return si.uptime; return -1; }btw. war der 2. Treffer bei google
-
long uptime; /* Seconds since boot */
-
Ich wollte nur anmerken, dass ich noch keine Lösung gefunden habe
-
eventuell mit dem rdtsc CPU-Befehl?
-
denke seit cool & quiet und aehnliches ist ein umrechen auf zeit mit rdtsc eher schwierig
-
... und ich fand: man: clock_gettime
-
Das war ja ne schwere Geburt
Nee im Ernst, kannte ich auch noch nicht und werde mir vornehmen, es nicht wieder zu vergessen, falls ich das auch mal brauche (oder mal jemand fragt :D), zumal das nichts exotisches sondern POSIX Standard ist.
-
LordJaxom schrieb:
zumal das nichts exotisches sondern POSIX Standard ist.
Mac OS X/Darwin haben es trotzdem nicht
-
Jetzt habe ich ein weiteres Problem gehabt: sowohl usleep als auch nanosleep schlafen länger, als sie sollen. IdR brauchen beide Funktionen 2ms zu lange. Ich habe nun umständlich ein eigene Schlaf-Funktion gemacht, welcher einen Teil der Zeit mit nanosleep abdeckt und den Rest in einer Endlodschleife abwartet, was eine hohe CPU-Zeit und 0-2% Auslastung durch die Schleife zur Folge hat. Dafür habe ich in 95% der Aufrufe eine Abweichung von 1µs.
-
2ms können gut vom Scheduling kommen. Wenn du sleep benutzt, sagt das Programm dem Scheduler ja "Wecke mich in x ms" und wenn gerade kein Zeitfenster zur Verfügung steht, dann dauert es, bis dein Prozess geweckt wird.
Wenn du aber eine Endlosschleife hast, dann bekommt dein Programm ja ständig Rechenzeit.
Vielleicht hilft es ja die Priorität des Prozesses anzuheben (man: setpriority(2)). An sonsten benötigst du wohl Realtimeerweiterungen
-
Priorität habe ich schon von 0 auf 10 erhöht (die Linux-Prioritäten sagen mir nicht wirklich viel ;))
Was ist eine Realtime-Erweiterung? Die Sleep-Funktion ist übrigens für einen Gameserver.
-
Wenn Du mit Priorität nice-Werte meinst, da sind die niedrigeren höher, will heissen -19 ist die höchste Priorität
-
Wieso hat Teamspeak dann einen Wert von 19?
*edit* Kann es sein, dass nur der root einen Nice-Wert < 0 setzen darf?
-
Ist richtig, negative (also hohe) Prios sind root vorbehalten.
-
LordJaxom schrieb:
Hallo,
Die Funktion gettimeofday liefert Dir Mikrosekunden ganz ohne Überlauf
Ich benutze immer folgende Funktion wenn ich Zeitmessungen machen will (ohne mit den zwei Membern der timeval struct hantieren zu müssen):
uint64_t getTimeMs(void) { struct timeval tv; gettimeofday(&tv, 0); return uint64_t( tv.tv_sec ) * 1000 + tv.tv_usec / 1000; }Seit wann Microsekunden? Sollten das nicht Millisekunden sein? Microsekunden seit 1970 ist selbst für nen unsigned long zuviel.