QueryPerformanceCounter
-
Das ist was für einen Simplen Dreisatz...
Rechne doch mal aus, wann ein LARGE_INTERGER überläuft, wenn er mit heutiger Prozessortaktung (also gehen wir mal von 100 GHz aus, dann haben wir die nächsten 3 Jahre auch schon abgedeckt) gezählt werden würde.
-
Mmacher schrieb:
Somit: bei Auswertung (i.d.R. ist das meistens Differenz bilden, um eine verstrichene Zeit zu messen) also auf diesen Überlauf hin checken.
Also nochmals: WANN läuft der Zähler über?
-
Jochen Kalmbach schrieb:
Also nochmals: WANN läuft der Zähler über?
willst du damit jetzt sagen, dass man die möglichkeit des überlaufs einfach ignorieren soll?
selbst wenn es nach heutiger technik 350 jahre dauern würde bis ein überlauf stattfindet, sollte man es trotzdem checken.
durch eine denkweise wie deine ist damals windows 95 nach 49,7 tagen abgestürzt.
-
_< hat wer nen artikel dazu ? ich habs immer gehört das da mal sowas war aber nie gelesen.
jedenfalls danke _ by the way überlauf iss erstmal unkritisch .... kritischer isses das ich beim dualcore auf ein und demgleichen CPU bleibe beim query um net 2 unterschiedliche takte zu zählen .... da fällt mir ein ich wollt ja den test mit der frequency und der taktbaren centrino CPU machen >_<
-
http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://support.microsoft.com/kb/895980es gibt unter windows leider keine 100% verlässlichen timer mit vernünftiger auflösung.
-
mit dem artikel meinte ich eigentlich den andere comment
durch eine denkweise wie deine ist damals windows 95 nach 49,7 tagen abgestürzt.
-
das checker schrieb:
Jochen Kalmbach schrieb:
Also nochmals: WANN läuft der Zähler über?
willst du damit jetzt sagen, dass man die möglichkeit des überlaufs einfach ignorieren soll?
selbst wenn es nach heutiger technik 350 jahre dauern würde bis ein überlauf stattfindet, sollte man es trotzdem checken.
durch eine denkweise wie deine ist damals windows 95 nach 49,7 tagen abgestürzt.
Es ist nicht richtig, dass ein Überlauf berücksichtigt werden muss. Wird eine korrekte Subtraktion zwischen dem Wert vor und nach dem Überlauf durchgeführt, dann kommt ein korrektes Ergebnis heraus.
Einziges problem. Sollte zwischen den Aufrufen mehr als 3 Jahre vergehen
kann nicht mehr festgestelt werden wieviele Überlüfe es gab.Als Anregung dazu, dass en Überlauf nichts macht empfehle ich Dir die Doku zu GetTickCount. Dort wird beschrieben wie gerechnet werden muss.
Verwendet man immer Subtraktionen fragt den GetTickCount häufiger als alle 49,7 Tage ab, dann ist das Ergebnis selbst bei einem Überlauf definiert und korrekt.When using GetTickCount, subtraction is safe but comparisons such as if (GetTickCount() > MyTickCount) are not. You can use the GetTickCount function to time the duration of an activity as shown in the example below, but using GetTickCount for any other operation will cause issues.
Copy Code
dwOldTime = GetTickCount();
DoSomething();
dwTimeElapsed = GetTickCount() – dwOldTime;Oder anderes Beispiel aus der MSDN:
The following example demonstrates how to use a this function to wait for a time interval to pass. Due to the nature of unsigned arithmetic, this code works correctly if the return value wraps one time. If the difference between the two calls to GetTickCount is more than 49.7 days, the return value could wrap more than one time and this code will not work; use the system time instead. Note that TIMELIMIT is defined as the time interval of interest to the application, in milliseconds.
DWORD dwStart = GetTickCount();
// Stop if this has taken too long
if( GetTickCount() - dwStart >= TIMELIMIT )
Cancel();Gleiches gilt für QueryPerformanceCounter!
Der Absturz von Windows98 wurde dadurch verursacht, dass einige Windows 98 Leute sich nicht an die eigene Doku gehalten haben... aber das kommt öfters auch woanders vor
-
Martin Richter schrieb:
Es ist nicht richtig, dass ein Überlauf berücksichtigt werden muss.
du hast recht, nach kurzem drüber nachdenken kommt man auch drauf. ob jochen das so im hinterkopf hatte als er nach dem zeitpunkt des überlaufs fragte, ist eine andere frage.
-
mit QueryPerformanceCounter() gibts bei multicore keine probleme (die gibts nur wenn z.b. rdtsc im spiel ist), weil der performance counter _nicht_ in der cpu ist.
-
... habe ich nun festgestellt, das der performance counter murks iss .... der driftet mir zu sehr zum echten tickcount ... selbst wenn ich jede hundertstel zehntel millisekunde ausrechne (um übertragsfehler zu vermeiden weil frequenz in count / SEKUNDE gerechnet werden ich aber * 1000 rechnen muss um auf ms zu kommen) driftet der zähler am tag kanpp was um die 5 sekunden vorwärts bei mir
ich hab mich entschieden mit timeGetTime zu arbeiten, nach zahlreichen tests scheint mir diese funtion am päzisesten und zuverläsigsten zu sein
-
-
Ceos schrieb:
... habe ich nun festgestellt, das der performance counter murks iss .... der driftet mir zu sehr zum echten tickcount
qpc ist auch nicht dafür gedacht, über mehrere stunden absolut akkurate ergebnisse zu liefern. das augenmerk liegt eher auf hoher auflösung als auf präzision.
wenn dir 1 ms auflösung reicht, ist timeGetTime sicher die bessere wahl.
-
Ceos schrieb:
ich hab mich entschieden mit timeGetTime zu arbeiten, nach zahlreichen tests scheint mir diese funtion am päzisesten und zuverläsigsten zu sein
Das stimmt nicht. QueryPerformanceCounter() ist der präziseste Counter, den deine Hardware hergibt. Du machst einfach was falsch.
-
das checker schrieb:
qpc ist auch nicht dafür gedacht, über mehrere stunden absolut akkurate ergebnisse zu liefern.
Sondern? Über mehrere Minuten nur? Was für ein Unsinn. Je genauer ein Counter ist (und QPC ist der genaueste) desto länger weicht er nicht auch nur um 1 Sekunde ab.
-
sry, aber das stimmt nicht. die jumps des QPC z.b. sind ein weithin bekanntes problem. nur weil er eine hohe auflösung hat, bedeutet das nicht, dass er auch "genau" ist (was immer das heißen mag). QPC ist, wie die meisten hochauflösenden timer, dazu gedacht, sehr kurze/schnelle vorgänge zu messen und nicht um die exakte uhrzeit zu berechnen.
-
Das stimmt nicht. QueryPerformanceCounter() ist der präziseste Counter, den deine Hardware hergibt. Du machst einfach was falsch.
scherzkeks, zeig mir mal deine formel bitte um ms zu berechnen ... teste es einfach mal selber der drift iss definitiv da
Sondern? Über mehrere Minuten nur? Was für ein Unsinn. Je genauer ein Counter ist (und QPC ist der genaueste) desto länger weicht er nicht auch nur um 1 Sekunde ab.
gettickcount wird nur spärlich inkrementiert, dafür aber genau, QPC inkrementiert oft == hohe auflösung != genauigkeit
ums genauzunehmen, wenn du mit der uhr dasitzt und alle sekunden auf einen zettel 1 strich setzt, iss das auf dauer synchroner mit der echten zeit als wenn du immerfort striche ziehst, über sagen wir 1stunde die anzahl nimmst und dann die frequenz ausrechnest und dann über die frequenz (wo auch hin und wieder drift entsteht oder beim ausrechnen kommastellen rausfallen) wieder zur zeit rechnest.
da wird dir auf längerer zeit n gehöriger drift auffallen!
-
-
ja gut, den jump hab ich nicht berüchsichtigt ... das könnte eventuell auch die 3 sekunden betreffen die ich als drift über 24h gemessen habe, ABER ich hab definitiv einen drift, ich schätze es mal nur ab weil ichs nicht in eine datei permanent gespeichert habe, ich würde sagen etwa 1ms über 1-2 minuten driftet mir der performance count davon und das iss schon zu viel
-
wie schon gesagt, der performance counter ist auch nicht für sowas gedacht. wenn du die hohe auflösung trozdem brauchst, dann musst du z.b. alle paar sekunden mit einem anderen timer (z.b. GetTickCount()) synchronisieren.
-
jop ... aber bisher bin ich mit dem timegettime zufrieden und werd dabei wohl auch bleiben und einfach all 24h synchronisieren
