Große Abweichung zwischen Now und GetTickCount

[samso]

Wenn Du zwei verschieden Uhren (Performancecounter und Systemzeit) vergleichst, dann kann es je nach Qualität der Uhren schon zu erheblichen Abweichungen kommen. Solange Du keine der beiden Uhren mit einem exakten Zeitgeber (Atomuhr oder dergleichen) synchronisierst ist keine der beiden Uhren genau. Nach deinen Ausführungen scheint es bei Deiner Anwendung ja um eine Maschine zu handeln die abgeschottet von der Aussenwelt arbeitet und deren Uhr gelegentlich manuell nachgestellt wird.

So wie Du ausführst, willst Du lediglich einen Zeitsprung bei der Umstellung der Uhrzeit dokumentieren. Dann sollst Du doch sinnigerweise versuchen diesen Zeitsprung zu detektieren. Das finde ich vergleichsweise einfach. Du musst lediglich in halbwegs gleichmäßigen Zeitabständen (z.B. 200ms) prüfen, ob die Systemzeit um mehr als 3s von dem Zeitstempel vor 200ms abweicht. Ist das der Fall, dann hat jemand die Uhrzeit verstellt. Um die Sommerzeitumstellung korrekt zu berücksichtigen verwendest Du UTC (die bei der Sommerzeitumstellung gleichmäßig weiter läuft).

Delphi-Quellcode:

function NowUTC: TDateTime;
var
  SystemTime: TSystemTime;
begin
  GetSystemTime(SystemTime);
  Result := SystemTimeToDateTime(SystemTime);
end;

[Hobbycoder]

Korrigiert mich wenn ich falsch liege, aber GetTickCount benötigt ja sinngemäß keinerlei Zeitanpassung, und kann somit ab Programmstart kontinuierlich mit rechnerspezifischem Takt fortlaufen. Now jedoch bedient sich der Systemzeit, die per NTP in bestimmten Intervallen angepasst wird, und demnach irgendwann von GetTickCount abweichen muss.

Wäre da nicht ein Vergleichstest auf möglichst vielen unterschiedlichen Rechner, und das raus ermittelte Mittelmaß der Abweichung notwendig um objektive darüber zu Diskutieren?

[Delphi.Narium]

Mal nur Spekulation:

GetTickCount ist doch quasi ein eigener Zähler, quasi eine Timer von Windows.

TDateTime ist eine Uhrzeit, unabhängig vom gerade laufenden System, die ggfls. extern geändert werden kann, sei es vom Anwender, vom Betriebssystem (wegen Sommer-/Winterzeit, eines Dienstes, Zeitsynchronisation mit Zeitserver ...)

Wenn nun in der VirtualBox TDateTime geholt wird, müssten die Werte von TDateTime mit der "realen Aussenwelt" synchron laufen.

Wenn aber in der VirtualBox der Timer für GetTickCount etwas langsamer läuft, als der von einem Windows, dass "direkt auf der Hardware" läuft, einem anderen Rechner, einem anderen Systemstart, ..., so muss sich hier eine Abweichung "hochschaukeln".

GetTickCount function

Zitat:

Remarks

The resolution of the GetTickCount function is limited to the resolution of the system timer, which is typically in the range of 10 milliseconds to 16 milliseconds. The resolution of the GetTickCount function is not affected by adjustments made by the GetSystemTimeAdjustment function.

Wir haben hier also laut Microsoft eine "Ungenauigkeit" von bis zu 6 Millisekunden.

Der Effekt ist also ähnlich dem, den Du mit zwei Timern erhalten kannst, bei dem einer mit 'nem Intervall von 1000 und einen mit 'nem Intervall von 1001 laufen lässt. Wenn Du bei denen hergehst und die zum Zeitpunkt der jeweiligen Timerauslösung gelesenen TDateTIme-Werte gegenüberstellst und 1:1 vergleichst, so muss eine Abweichung entstehen.

Der Wert vom 1. Timer beim 1. Auslösen ist zwangsläufig anders, als der Wert vom 2. Timer beim 1. Auslösen.
...
Der Wert vom 1. Timer beim 100. Auslösen ist zwangsläufig anders, als der Wert vom 2. Timer beim 100. Auslösen.

Die Differenz ist dann eben 100 Millisekunden.

Wenn also das Intervall von GetTickCount in 'nem Bereich von 10 bis 16 Millisekunden liegt und man diese Werte von mehreren Systemen vergleicht, so müssen (fast) zwangsläufig Differenzen auftreten.

TDateTime ist aber, unabhängig vom System (also Windows direkt, oder Windows in VirtualBox) immer gleich.

Differenzen bei der Messung sind auf die unterschiedlichen "Verarbeitungszeiten" zur Ermittlung der Daten zurückzuführen, mehr oder weniger CPU-Last abhängig, sollten aber über die Zeit nicht wesentlich voneinander abweichen, also in einem sehr begrenzten Bereich um +/- 0 laufen.

Oder anders:

Bei einem Vergleich von GetTickCount mit TDateTime vergleichst Du kontinuierlich die Zeiten zwischen einer permanent gleichmäßig "falschgehenden" Uhr (immer zu schnell oder immer zu langsam) mit einer Uhr, die regelmäßig gestellt wird.

Früher hatten die mechanischen Uhren ein kleines Stellrädchen, mit dem man die Geschwindigkeit, mit der sie liefen, feinjustieren konnte. Lief eine Uhr etwas zu schnell, so konnte man sie hier etwas langsamer stellen, lief sie etwas zu langsam, konnte man sie hier etwas schneller stellen, bis man den Punkt erreicht hat, dass sie dauerhaft korrekt lief.

Wurde diese Korrektur nicht durchgeführt, lief die Uhr dauerhaft falsch.

Und so läuft es mit GetTickCount. Der Timer läuft einmal beim Systemstart an (mit 'ner bekannten Ungenauigkeit von 6 Millisekunden), aber den Fehler hält er konsequent mit Genauigkeit bei.

Damit ist es eigentlich unmöglich einen parallelen Zeitverlauf zu einer Zeitmessung zu erhalten, deren mögliche Abweichungen permanent korrigiert werden.

[himitsu]

Die Virtualisierung ist etwas langsamer und kann je nach Auslastung von Host und ClientVM auch mal kurz hängen, also muß die VM da ein Bissl was kompensieren, denn die "Uhrzeit" soll ja dennoch konstant laufen, also wird die Uhr in der VM immer wieder ein klein bissl nachreguliert, während aber die anderen Counter anhand der CPU-Takte ungeguliert weiterzählen.
Das mit der VM hätte man also besser gleich mit erwähnen sollen.

PS: Bei einigen VMs (z.B. VirtualBox) kann man diese Synchronisierung abschalten und sogar verschieben,
dann läuft die Uhr der VM aber natürlich immer etwas oder mehr nach (weil es ja immer wieder bissl jängt)
und man kann die VM sogar geziehlt in der Vergangenheit oder Zukunft laufen lassen.

So kannst z.B., ohne die Uhr im Host zu ändern, in der VM das 2000er-Problem von DOS/Windows nochmal nachstellen, oder den Weltuntergang im Linux jetzt schon ausprobieren, wenn dort 2038 der Timer überläuft.



PS: Entsprechend dem QueryPerformenceCounter ein kleines Beispiel Anhand des Time Stamp Counter (TSC, bzw. RDTSC = ReaD TSC).
Der lief früher immer synchron mit dem CPU-Takt, womit man also extrem genau messen konnte, wie schnell ein/mehrere Befehle sind.
Dann wurde MultiCore erfunden, was noch gut lief, da alle Kerne gleich schnell liefen und es nichts ausmachte, selbst wenn jeder Kern seinen eigenen Zähler hat.

Als aber die Kerne dynamisch anfingen sich je nach Auslastung unterschiedlich zu takten, fing der Spaß an:
Du beginnst die Messung, während dein Thread auf dem einen Kern läuft, stoppst sie aber auf einem anderen Kern, die beiden Zähler liefen vorher und währenddessen unterschiedlich schnell, also passiert es dass deine "berechnete" Messung extrem lange dauert (obwohl es schnell war) oder sogar ein negatives Ergebnis liefert usw.

Zum Schluß wurde die CPU auf einen virtuellen Zähler umgebaut, der neben den Kernen läuft, womit alle Kerne die selbe Zeit bekommen.
Jetzt ist es wieder möglich die "reale" Geschwindigkeit zu messen, aber auf einen Kern und dessen aktuelle Taktung eben nicht mehr die "wirkliche" Laufzeit -> "Anzahl der Befehls-Takte".

[norwegen60]

Hallo zusammen,

ich habe jetzt noch parallel per Stopuhr alle 10 Sekunden ein Zeitstempel erzeugt. Im Anhang das Chart, das eindeutig zeigt, dass QueryPerformcounter mit meinen manuellen Zeitstempel synchron ist.
Die Uhr eiert also tatsächlich um bis zu 30s und GetTickCount wandert mit der Zeit weg. Alles bezogen auf VirtualBox

Im Anhang auch der Real-PC nach 100 Minuten. Da läuft nichts weg.

Ausserdem das komplette Projekt zum selber Testen.
Zur Funktion

• btStart startet Zeitmessung
• Click auf btStopUhr setzt Focus auf btStopUhr
• Danach kann per Leertaste alle 10s manueller Zeitstempel gesetzt werden. Der ist aber ganz simpel gestrickt. Wenn man mal vergisst zu Klicken, muss man zwei mal klicken um den Zähler wieder zu synchronisieren.
• Bezüglich meiner ersten Code-Beispiele habe ich X-Achse auf Werte umgestellt, da der manuelle Zeitstempel nur alle 10s erfolgt und dann auf den korrekten Zeitpunkt gesetzt werden muss

[norwegen60]

Zitat:

Zitat von himitsu (Beitrag 1463458)

Das mit der VM hätte man also besser gleich mit erwähnen sollen.

Ja, wenn man gleich ahnen würde woher was kommt, wäre manches Problem einfacher:-D
Ich bin nicht davon ausgegangen, dass die Effekte so groß sein können

[norwegen60]

Zitat:

Zitat von Delphi.Narium (Beitrag 1463454)

Damit ist es eigentlich unmöglich einen parallelen Zeitverlauf zu einer Zeitmessung zu erhalten, deren mögliche Abweichungen permanent korrigiert werden.

Dass die Uhr Einschränkungen hat, habe ich ja gleich im ersten Beitrag gesagt und ist auch die Ursache, dass ich nach einer "genauen" Alternative gesucht habe. Dass die Uhr in der VirtualBox aber so ungenau ist, hat mich überrascht

Im realen PC habe ich noch nie festgestellt, dass GetTickCount wirklich deutlich weg läuft. Und bisher bin ich davon ausgegangen, dass auch VirtualBox bei GetTickCount auf den Countgeber des realen PC zurück greift. Das hat sich als falsch erwiesen.

Die Frage für mich war einfach: Was stimmt denn am genauesten. Und so wie es aussieht ist das QueryPerformanceCounter

[norwegen60]

Zitat:

Zitat von Hobbycoder (Beitrag 1463448)

Wäre da nicht ein Vergleichstest auf möglichst vielen unterschiedlichen Rechner, und das raus ermittelte Mittelmaß der Abweichung notwendig um objektive darüber zu Diskutieren?

Es geht mir nicht darum eine Zeit auf's hunderstel genau zu ermitteln. Nur die Schwankungen, die ich in meinen Charts aufgezeigt habe sind da und sie sind enorm. Die VirtauBox ist auf 2 Laptops gelaufen und die Ergebnisse sind ähnlich schlecht. Da brauche ich dann nicht möglichst viele anderen PC's um zu sehen, dass es andere PC's gibt, die besser oder noch schlechter sind.
Ich brauche eine Lösung, der ich auch auf der VirtualBox am meisten vertraue. Nach dem Vergleich mit der manuellen Stopuhr ist das ganz klar QueryPerformCounter.

[himitsu]

https://stackoverflow.com/questions/...est-at-runtime

Und was passiert danach?


Auch kann es beim Test nicht schaden mal im Host die Festplatte und CPU bissl auszulasten,
um die Auswirkungen des Host besser erkennen zu können.
Denn wenn du jetzt etwas als gut erachtest und auch dort "extreme" Abweichungen entstehen können, dann wäre dieses "gut" eventuell nicht "gut" genug.

Wobei die Abweichung dennoch hoch sein darf, so lange es konstant bleibt bzw. ansteigt, anstatt "zufällig" zu schwanken.
Auch ein Schwanken kann OK sein, denn wenn das System durch die Virtualisierung hängt/bremst, die Messung aber im Vergleich zu einem realen System sich vergleichbar verhält, dann stimmt dennoch das Ergebnis.

Beispiel: VM anhalten/pausieren und eine Stunde später wieder starten. (de extreme Variante eines kurzen Hängers)
Aus Sicht der VM und ihrer Programme ist dann nicht "wirklich" eine Stunde vergangen.

[norwegen60]

Ich werde weiterhin ein Auge darauf habe. Ich war anfangs nur ziemlich überrascht, wie stark die Effekte sein können.
Ich habe mein Test-Projekt dahingehend geändert, dass QueryPerformanceCounter meine Basis ist. Und da sieht man dann:

• wie GetTickCount in der VM kontinuierlich weg läuft und auf meinem Real-PC konstant bleibt
• wie der Vergleich zur Uhrzeit genau gleich weg läuft, dann aber immer wieder synchronisiert wird und damit parallel bleibt.
• wie die Abfrage mit Now während der Synchronisation um 1.5s schwankt

Mal schauen, ob ich über längere Zeit auch die Schwingungen des ersten Langzeittest wiederfinden kann. Denn nur, wenn man mit seiner Zeitmessung zu einem solchen Zeitpunkt startet, werden auch die Differenzen so groß wie ich sie anfangs hatte.
Mit den 1.2s die ich jetzt in der VM habe, kann ich gut leben. Und auf dem real-PC sind es nur 0.001s

Im Anhang noch mal der Lanzeittest mit Zeit als Basis (TimeGetTickCount3) und dann der neue Test mit QueryPerformanceCounter als Basis (TimeGetTickCount7)
Dazu das aktuelle Projekt incl. exe.