realtimeclock mit ms genauer gettime funktion
-
ich habe hier einen alten Timer der mit einer VCL komponente arbeitet aber millisekundengenaue ausgaben bringt, beim versuch das ohne VCL umzusetzen scheitere ich an der ungenauen GetTickCount() methode ...
hat jemand eventuell eine idee wie ich das geschickter lösen kann?!die VCL-Komponente hat regelmäig einen synchronisationsblock generiert mit zeit und einem __in64 tickcount, anhand dessen man die zeitdifferenz berechnen kann ... die frage ist wie ich jetzt einen millisekunden genauen tick erhalten kann (möchlichst auch 64bit int) der auch wirklich möglichst präzise ist.
hab da was gefunden
http://www.delphipraxis.net/post261996.html&sid=efee35ccc26c52253fdc7e35de358809#261996
das sieht doch nach nem präzisen tickcount aus ... muss ich nur in c++ umsetzen, bzw. iss das so auch in linux machbar mit dem performancecounter?ist die GetSystemTime() methode auch in linux verfügbar ?
ich hatte angedacht das ich alle 24h eine synchronisation mache mit einer struktur in der art ....
struct SyncBlock { __int64 tick, //zählt ab der initialisierung der timerklasse SYSTEMTIME SycTime // SYSTEMTIME struktur der zeit zum angegebenen tick }so sollte ich bei übermittlung des tick mit den daten und einem vorhandenen syncblock doch die server-zeit vernünftig und sogar msec genau hinbekommen
-
GetSystemTime gibts in der Form nicht, dafür 100 andere absolute time APIs. Leider nur eine mir bekannte relative, die nicht auf allen Systemen vorhanden ist: clock_gettime mit CLOCK_MONOTONIC.
Heisst under BSD dann clock_get_time (ich glaube mit geringfügig anderer Funktion, aber "im Prinzip" dasselbe).
-
ich hab jetzt ganz trivial gemacht, ich merk mir timestamps mit geringer genauigkeit (getlocaltime() mit darauffolgendem queryperformancecout() vermutliche genauigkeit 20ms zur systemuhr) und mithilfe des performance counters rechne ich mir die zeit anhand des timestamps zurück (systemtimetofiletime -> addieren -> filetimetosystemtime), so hab ich von einer gleichbleibend genauen zeitangabe mit der genauigkeit des performance counter _
eine frage stellt sich mir jedoch, was passiert mit dem performance counter wenn ich die cpu "runterregle" (centrino cpu und so laptop energiesparfunktionen)
PS werd ich morgen mal auf meinem laptop selber testen, aber evtl. hat hier schon jemnd erfahrung damit gemacht
PPS iss zwar nicht mehr posix aber immerhin VCL frei ...
-
Ich verstehe nicht ganz was du machen willst...
BTW: GetTickCount nur aus Millisekunden genau heisst unter Windows timeBeginPeriod + timeGetTime.
Die SYSTEMTIME Struktur und der Tick Count passen allerdings nicht ganz zusammen - der Tick Count zählt ununterbrochen vor sich hin, die System Time dagegen unterliegt oft Schwankungen durch die Anpassung über (S)NTP.
D.h. die System Time "driftet" gegenüber dem Tick Count. Bzw. springt sogar wenn man das Datum umstellt.
-
es geht nur darum eine gleichbleibende relative zeit im bezug auf eine synchronisation zwischen systemuhr und tickcount zu haben ... ich mach beim start des programms einen zeitstempel um punkt 8uhr z.B. der tickcount steht bei 20000 wenn ich jetzt 3 mal schnell hintereinander ein datenpaket empfange und 3 mal gettickcount aufrufe erhalte ich 2 mal 20500 und dann einmal 20518 weil der tickcount nur mit 18ms auflösung arbeitet (das sind alles einfach mal angenommene werte) jetzt rechne ich die zeitdifferenz des tickcounts auf die uhrzeit der synchronisation auf und erhalte 8:xx:xx.xxx .
mit dem queryperformancecounter wollt ich die genauigkeit steigern indem ich den echten gettickcount mit dem performancecounter ersetze (im alten programm war für eine ähnliche mit VCL behaftete zeitmessung ebenfalls __int64 werte vorgesehen)
EDIT: timeBeginPeriod + timeGetTime was bewirkt das ? ich hab ne ahnung aber grad nicht die möglichkeit nachzuschauen bzw. ich hab grad nich die zeit nachzuschaun
-
> timeBeginPeriod + timeGetTime was bewirkt das
Du machst erst timeBeginPeriod(1), danach bekommst du von timeGetTime genauso 32 Bit Werte wie von GetTickCount, nur mit 1ms Auflösung statt 15ms.Um Timestamps für Pakete zu generieren nimmt man allerdings normalerweise QueryPerformanceCounter oder einfach RDTSC - je nachdem (RDTSC kann anscheinend auch die Frequenz wechseln, QueryPerformanceCounter sollte das nicht).
Nur kannst du wie gesagt nicht auf eine "Uhrzeit" zurückrechnen, zumindest nicht zuverlässig.
-
-
Wenn ich schonmal da bin,
ich verwende timeGettime(), wie genau ist diese funktion?
-
Laut MSDN so um die 5 Millisekunden - aber mit timeBeginPeriod() kannst du die Genauigkeit einstellen:
Windows NT/2000: The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine. You can use the timeBeginPeriod and timeEndPeriod functions to increase the precision of timeGetTime. If you do so, the minimum difference between successive values returned by timeGetTime can be as large as the minimum period value set using timeBeginPeriod and timeEndPeriod. Use the QueryPerformanceCounter and QueryPerformanceFrequency functions to measure short time intervals at a high resolution,
Windows 95: The default precision of the timeGetTime function is 1 millisecond. In other words, the timeGetTime function can return successive values that differ by just 1 millisecond. This is true no matter what calls have been made to the timeBeginPeriod and timeEndPeriod functions.
-
http://www.gamedev.net/reference/programming/features/timing/ schrieb:
timeGetTime (TGT): third tick counter, but its resolution can be improved to 1 ms via timeBeginPeriod (the clock interrupt frequency is increased). Note that this slows down the system disproportionately - interrupt latency goes up, and the CPU cache suffers. This function takes 102 clocks; I have not analysed what it does in detail.
-
genial;) so kann ich meine realtime engine aufmotzen;)
-
Unter Windows gibts noch QueryPerformanceCounter und QueryPerformanceFrequency, ist glaubich ziemlich genau
