Große Abweichung zwischen Now und GetTickCount

**KarstenK**

Hallo,

zu "The system can periodically refresh the time by synchronizing with a time source."

Die Zeitsynchronisierung per NTP ist in Windows etwas magic, es passiert nicht auf einmal, wenn die Zeitdifferenz klein ist, sondern past sich mit der Zeit an. (daher mein Interesse)

Schalte mal alle Netzwerkverbindungen aus um diesen Effekt auszuschliessen.

20 sec halte ich aber für nicht realistisch (scalierung in der Visualisierung?). Bei mir sind es -3 bis +3 ms (Ausreisser bis 9ms).

Kannst Du das Projekt mal hochladen?

Auf welcher hardware laufen deine Tests?

**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?

**norwegen60**

Zitat von Hobbycoder:

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.

**himitsu**

Jetzt noch in der Mitte der Messung mal eine Zeit lang einen CPU-Benchmak laufen lassen
und dann schauen wie GetTickCount und QueryPerformenceCounter sich verhalten.

Die Abweichung müsste dabei ja größer werden.
Bleibt QueryPerformenceCounter aber gleich, würde ich dennoch zu GetTickCount raten, denn das scheint ja, unter Kompensation der Auswirkungen der Virtualisierung, ein gutes Ergebnis zu liefern, im Verhältnis zur realen "Rechenzeit".

Aus Spaß und Langeweile kannst auch noch das mit einbauen. (den Test brauchst eigentlich nicht mehr, da wohl jede CPU das "inzwischen" hat)

http://michael-puff.de/Programmierun...UCounter.shtml

markieren

Delphi-Quellcode:

			function RDTSC: UInt64;  // oder Int64

asm 

  RDTSC

end;

Es kann aber dennoch nicht schaden hier den Prozess/Thread/MainThread an einen Kern zu binden ... sicher ist sicher.
MSDN-Library durchsuchen

SetProcessAffinityMask oder MSDN-Library durchsuchen

SetThreadAffinityMask

**norwegen60**

Jetzt sind auch die Schwingungen wieder aufgetreten. Ausgelöst durch den Start von SQL-Manager und einige SQL-Abfragen. Und tatsächlich weicht da dann die Uhrzeit der VM um 4s von der Uhrzeit des Original-Pc ab.
QueryPerformance ist davon aber unbeeinflusst, zeigt es doch die Abweichung korrekt an

Ich verstehe also nicht ganz warum ich bei GetTickCount bleiben sollte. Der läuft doch von der realen Zeit weg (blaue Linie)

**himitsu**

Ja, die VM hängt nunmal, also läuft deren Zeit weg und wird teilweise wieder mit der Realität synchronisiert.
GetTickCount läuft auch weg, aus unserer Sicht, aber nicht aus Sicht der VM.

Es kommt nun drauf an was man eigentlich messen will.
* die "virtuelle" Laufzeit von etwas in der VM, im Vergleich zu dem was man auch außerhalb messen würde
* die reale Laufzeit zur Realität außerhalb der VM

Beispiel: du hast einen grottenschlechten Emulator, der nur halb so schnell ist, wie das echte Gerät.
Will man da dann im Emulator die emulierte Zeit messen (also halb so schnell) oder die "echte" Zeit? Und wenn ja, was ist die "richtige" Echte, also im Verhältnis zu was?

Zeit ist eben relativ, wie so ein gewisser Typ mal bemerkte.
Die VM ist der Inhalt eines Raumschiffs bei nahezu Lichtgeschwindigkeit oder in der Nähe eines Schwarzen Lochs.
Im Raumschiff/VM läuft alles langsamer, aber für die Insassen ist das "normal".

Selbst ein Satellit in der Nähe der Erde ist etwas verschoben, aus unserer Sicht.
Oder zwei Uhren, Eine auf einem langsamen Kreuzfahrtschiff und die Andere in einem schnellen Flieger. Am Ziel haben die Uhren einen Unterschied, aber für beide Reisenden verlief die Zeit aus "ihrer" Sicht ganz normal.

Bei einem Planeten mit einer elyptischen Umlaufbahn ist im Sommer die Zeit langsamer, als im Winter, weil näher an der Sonne und damit schneller, aber auf dem Planeten bekommt das niemand mit, so lange er sich nicht mit einer externen Referenz vergleicht.
Aber wenn seine Referenz auch unbemerkt einer Schwankung unterliegt, dann misst der Messende schonmal Mist.

PS: Mit TIdTime kannst dich auch selber mit einem Zeitserver auf dem Host, deinem Router oder im Internet synchronisieren, also jeweils die aktuelle Zeit erfragen, dann bist unabhängig von dem Sync-Intervall der VM.
Musst aber bedenken, dass der Host sich auch mit einem externen Zeitserver synchronisiert, nur nicht in so extrem kurzen Abständen, wie in der VM.

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