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