Große Abweichung zwischen Now und GetTickCount

**norwegen60**

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.

**norwegen60**

Ich glaube nicht, dass ich unseren Kunden erklärt bekäme, dass ihre Tests halt auf einer langsamen VM gelaufen sind und deshalb etwas länger liefen als in der normalen Welt. Da halte ich mich also lieber an den irdischen QueryPerfomer und hoffe, dass der sich nicht auch irgendwo ablenken lässt und zu trödeln anfängt.

Ich wüsste außer unserer Entwicklungsumgebung auch keine reale Anwender, die das Programm in einer VM laufen lassen. Von daher hat sich die Problematik eh etwas entschärft.

**himitsu**

Brauchst doch nicht zu erklären?
Also falls die Verlangsamung sowohl Programm als auch den Counter gleicher Maßen betreffen, läuft es gefühlt vielleicht länger, aber gemessen wird das Gleiche.

Zitat:

Ich wüsste außer unserer Entwicklungsumgebung auch keine reale Anwender, die das Programm in einer VM laufen lassen.

Oder hast es nur nicht bemerkt?

Unser neuer Server, da läuft nun ein Linux und darin dann das Windows mit Delphi. (hatte dort nur mal ausversehn kurz reingesehn)
Aktuell ist es ein WindowsServer, der mehrere VMs mit Linux
und einer WinXP-Testumgebung (die ich zum Glück seit über einem Jahr nicht mehr besuchen musste).
und unserer Kunden haben auch schonmal Linux und Windows sonstiw gemischt.