QueryPerformanceCounter
-
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
-
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.
-
atm iss die zeit zu eng als das ich mich speziell nochmal damit auseinandersetzen kann, aber ich werd mich nochmal damit befassen, einen korrekturwert für den QPC zu ermitteln indem cih einfach über 10 sek oder so mitzähle ... by the way ich hab sogar einen timer zur verfügung der in etwa so arbeitet, mit jeder vollen sekunde wird der QPC sozusagen synchronisiert (und das wirklich sehr genau) aber hinten raus rennt der QPC manchmal vor oder er bleibt zurück, kam immer auf den verwendeten PC drauf an .... das sah dann so aus das die sekunden umsprangen die QPC-berechneten millisekunden aber noch bei .997 oder so waren das ist sehr unschön! manchmal auch umgekehrt aus 5.999 wird 5.001 wird 6.005
-
womit wird er denn synchronisiert? ich vermute mal, dass hier eher die synchronisationsquelle das problem ist und nicht qpc.
-
das checker schrieb:
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.
