0 bis max oder 0 bis max (plus) zu max (minus) und wieder 0 oder gar noch anders???

bzw. macht das eigentlich einen unterschied ?

sry für die (eigentlich simple) frage aber bei 64bit weis ich nich sicher wie der die vorzeichen handhabt

Somit: bei Auswertung (i.d.R. ist das meistens Differenz bilden, um eine verstrichene Zeit zu messen) also auf diesen Überlauf hin checken.

LARGE_INTEGER (also signed) ist nur eine Definition in einer Header-Datei, der tatsächliche Informationsgehalt ist ein unsigned Wert!

Hoffe, dies kann Dir weiterhelfen?
Martin

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?

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 >_<

es gibt unter windows leider keine 100% verlässlichen timer mit vernünftiger auflösung.

durch eine denkweise wie deine ist damals windows 95 nach 49,7 tagen abgestürzt.

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

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.

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

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.

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.

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!

btw:

http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q274323&

Sondern? Über mehrere Minuten nur? Was für ein Unsinn.

wenn du viele messungen akkumulierst und das ergebnis mit echtzeit vergleichst, wirst du eine mehr oder weniger große diskrepanz feststellen. qpc liefert für kurze zeitspannen genaue (aber nicht 100% akkurate!) ergebnisse. die sollte man nicht einfach aufsummieren, weil man damit die fehler mit aufsummiert.
wenn man schon aufsummieren muss, sollte man eine entsprechende fehlerkompensation berücksichtigen.

Optimizer schrieb:

Sondern? Über mehrere Minuten nur? Was für ein Unsinn.

wenn du viele messungen akkumulierst und das ergebnis mit echtzeit vergleichst, wirst du eine mehr oder weniger große diskrepanz feststellen. qpc liefert für kurze zeitspannen genaue (aber nicht 100% akkurate!) ergebnisse. die sollte man nicht einfach aufsummieren, weil man damit die fehler mit aufsummiert.
wenn man schon aufsummieren muss, sollte man eine entsprechende fehlerkompensation berücksichtigen.

Da hat es einer erkannt. Wenn man QPC falsch benutzt (zum Beispiel einzelne Abschnitte aufsummiert), kann natürlich über einen Tag schon 3 Sekunden abweichung entstehen. Oder wenn man auf den Query WARTET und dann erst wieder zum Zeit messen anfängt. Auch immer wieder sehe ich, dass Leute die Ticks in irgendwas umrechnen und diese Dinger aufsummieren. Das ist falsch und wer sowas macht, braucht sich nicht beschweren. Der Rest sind Fehler in der Hardware oder im BIOS.

Ceos schrieb:

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.

Wer macht denn auch sowas? Du musst immer fragen "wieviele Striche sind vergangen seit ...". Und nicht aufsummieren. Das ist doch mal klar. Hat aber gar nichts mit QPC zu tun.

Und du darfst nicht durch das Striche aufzeichnen oder ausrechnen was verpassen. Wenn du logisch gesehen keinen Strich verpasst (wenn du zu langsam zeichnest musst du halt immer 3,87897234234 Striche zeichnen) ist alles in Ordnung und je mehr Striche in der Sekunde, desto genauer.

Das sieht man doch schon daran, wie die Zeitmessung im echten Leben funktioniert. Man sucht etwas, das möglichst schnell tickt. Ein Cs-Atom schwing irgendwie mit 9,192631770 GHz, das ist schon mal nicht schlecht. Weil die Genauigkeit der Atomuhr aber noch verbessert werden soll, plant man Frequenzkämme einzusetzen, die irgendwie Quantenoptisch mit ein paar Terrahertz schwingen.