Große Abweichung zwischen Now und GetTickCount

[norwegen60]

Hallo zusammen,

ich bin gerade über etwas gestolpert, das ich nicht erwartet hätte:

Um von einer eventuellen Änderung der Zeit unabhängig zu sein (z.B. Sommer-/Winterzeit, oder Zeitkorrektur) messe ich die Zeit über GetTickCount. Ich weiß, dass die Auflösung irgendwo um die 16ms liegt, aber das ist eigentlich kein Problem.

Durch Zufall habe ich bemerkt, dass die über GetTickCount kalkulierte Zeit teilweise größere Abweichungen bekommen. Zuerst dachte ich es sei irgendwo ein Fehler, aber es lässt sich recht leicht nachvollziehen und Fehler sehe ich da keinen:

Delphi-Quellcode:

procedure TForm7.btStartClick(Sender: TObject);
begin
  iStart := GetTickCount;
  dtStart := now;

  tiTest.Enabled := not tiTest.Enabled;

  lsDelta.Clear;
end;

procedure TForm7.tiTestTimer(Sender: TObject);
var
  dt1, dt2: TDateTime;

begin
  dt1 := now;
  dt2 := dtStart + (GetTickCount - iStart) / (1000 * 24 * 60 * 60);

  lsDelta.Add((dt1-dt2)*24*60*60);
end;

Um das ganze zu visualisieren im Anhang ein Printscreen. Die Kurve hängt auch davon ab, wann man startet. Ich hatte auch mal eine Kurve die ist Sinusförmig rauf und wieder runter, dann aber ziemlich lang um die 10s Abweichung rum gependelt.
Im Chart noch eine zweite Kurve (orange), wo ich die Ticks mit QueryPerformanceCounter erfasst habe.
Über den Timer habe ich alle 1000ms die Abweichung berechnet und im Chart in [s] eingetragen

Hat jemand eine Erklärung?
Und vor allem, wie kann ich die Zeitmessung von Uhrzeit-Veränderungen unabhängig und genau machen?

Verwendet wird Delphi XE und Win7

Grüße
Gerd

[Uwe Raabe]

Now ist am Ende ein Aufruf von GetLocalTime, das einen SYSTEMTIME Record füllt. Für dieses gilt in den Remarks:

Zitat:

The system can periodically refresh the time by synchronizing with a time source. Because the system time can be adjusted either forward or backward, do not compare system time readings to determine elapsed time.

[norwegen60]

Ich weiß nicht ob ich da was missverstehe, aber genau das ist ja der Grund weshalb ich eigentlich nicht mit Now arbeiten will.

Kurzfristig sollte ein Vergleich aber doch kein Problem sein. Da verstehe ich nicht, dass der Wert innerhalb weniger Minuten um bis zu 20 Sekunden schwankt.
Die Uhr läuft doch in der Zeit nicht um 20s "unrund"

Im Anhang das Chart nach 70 min. Da hat sich QueryPerformanceCounter um 0 stabilisiert, GetTickCount nähert sich immer mehr der 20s Abweichung. Die Uhrzeit wurde in der Zeit nicht verstellt.

Beide Achsen im Chart sind [s]

[Medium]

µC (was CPUs letztlich sind) sind schrecklich ungenaue Uhren. Mehr News um 11 (oder kurz davor oder danach).

[Der schöne Günther]

Was genau ist deine Absicht?

Wenn du Zeiten miteinander vergleichen willst und dich dabei auch nicht von Dingen wie Sommer/Winterzeit
-Umstellungen aus dem Takt bringen lassen willst dann nimmt man keine lokale Uhrzeit sondern die Zeit in UTC. Für die Anzeige eines TDateTime für den Benutzer auf dem Bildschirm kann man dann UTC wieder in die lokale Zeitzone umrechnen.

[Ghostwalker]

Du arbeitest in deinem Beispiel mit, im übertragenen Sinn, Äpfel, Birnen und Pfirsichen :)

Now ist, wie Uwe schon angemerkt hat, die normal Systemzeit abhängig von der Zeitzone usw. Dabei wird, in Delphi, das ganze als TDateTime-Wert gespeichert. Dieser gibt im Vorkomma Teil die Anzahl der Tage seit dem 30.12.1899 (frag mich bitte nicht warum dieses Datum) an, im Nachkomma Teil, den Anteil der Zeit, die von den 24 Stunden vergangen sind an.

GetTickCount (besser GetTickCount64) gibt dir die Millisekunden seit Systemstart an. Damit ist das ganze soweit unabhängig von irgendwelchen Datums-/Uhrzeiten.

QueryPerformanceCounter ist ähnlich, aber wesentliche genauer. Abhängig ist das ganze aber von der Frequenz, in der gemessen werden kann (QueryPerformanceFrequency).

Was ich an deinem Beispiel kritisch sehen ist folgende Zeile:

Code:

dt2 := dtStart + (GetTickCount - iStart) / (1000 * 24 * 60 * 60);

Denn hier mischt du einen Wert, basieren auf der aktuellen Systemzeit (mit Zeitzone und Sommer-/Winterzeit), mit einem Wert basierend auf dem Systemstart. Noch dazu mit unterschiedlichen Datentypen (Integer und Double).

Je nachdem welche Zeitintervalle zu erwarten sind, würde ich auf TDateTime komplett verzichten und nur entweder mit GetTickCount64 oder QueryPerformanceCounter arbeiten. Wenn die Zeitintervalle größer sind, dann wie Günther schon anmerkte, mit TDateTime auf UTC.

Hoffe das hilft dir weiter. :)

[norwegen60]

Hallo zusammen,

ich glaube nicht dass ich Äpfel mit Birnen vergleiche. Ich vergleiche nur unterschiedliche Arten die eigentlich immer gleiche Zeit zu erfassen.

In dem Programm das ich betreue, werden zu bestimmten Zeitpunkten Messungen vorgenommen. Da muss in definierten Intervallen auch über längere Zeit (z.B. 30 Tage) innerhalb +/- 10 s gemessen werden (z.B. 30 Tage alle 60 Minuten oder aber auch 20 Minuten alle 2 Minuten)

Zu dem Messzeitpunkt wird auch die Datum/Uhrzeit dokumentiert. Wenn jetzt hin und wieder die Uhr nachgestellt wird, kann man das erklären. Wenn z.B. über den Sommer-/Winterzeit-Wechsel getestet wird, kann es sein, dass Prüfpunkt 11 um 2:45 gemessen wurde, Prüfpunkt 12 dann um 2:15. Um das zu erklären, soll das Programm künftig die Uhrzeit und eine "normierte Uhrzeit" vergleichen. Ist die Abweichung größer als 3s erfolgt ein Eintrag in ein Audittrail, dass die Uhr von außen verstellt wurde. Damit ist nachvollziehbar, warum sich die Benutzer-Uhr und unser Zeitgeber unterscheiden (Und damit auch die u.U. vom Benutzer über die eingetragenen Uhrzeiten nachgerechneten Intervalle).
Wenn aber solch seltsame Dinge auftreten wie in dem Chart kann man das kaum erklären. Bei einem Kurzzeittest, wo der Messintervall vielleicht nur 2 Minuten beträgt, glaubt niemand, dass die Uhrzeit halt mal 20s, mal 5s und dann wieder 20s korrigiert wurde.

Und egal, ob ich die Zeitdifferenz dann in Millisekunden (Integer) oder als Zeit (Double oder TDateTime) umrechne, sollten die in minimalen Grenzen gleich sein.

Im Anhang der Chart nachdem er die Nacht durchgelaufen ist (33600 s = 9:20 Stunden)
Wie man sieht sind die seltsamen Schwankungen zwei mal aufgetreten.
Die Messung der Dauer über QueryPerformanceCounter stimmt streckenweise ziemlich genau mit der überein, die ich über die Uhrzeiten gemessen habe.
GetTickCount weicht mittlerweile über 70s von der Zeit und QueryPerformanceCounter ab.

Ich glaube nicht, dass daran der folgende Code was ändert

Code:

dt2 := dtStart + (GetTickCount - iStart) / (1000 * 24 * 60 * 60);

Damit erschaffe ich mir nur eine isoliert Zeit. Ich werde es aber ausprobieren, ob sich was ändert wenn ich die Zeiten nur bei der Darstellung in eine einheitliches Format (dezimale Sekunden) ändere.

In der Nacht ist mir aber noch eine andere Vermutung gekommen. Das Programm incl. IDE läuft in einer VirtualBox. Vielleicht hat die negative Einflüsse.

Ich melde mich wenn ich dazu mehr weiß

[norwegen60]

Ein kurzer Zwischenstand. Es sieht so aus, als wenn die Ursache in VirtualBox liegt. Im Anhang die Charts im direkten Vergleich.

• Linkes Chart: Auf dem PC mit Win10: Nur wenige ms Abweichung und QueryPerfom genauer als GetTickCount
• Rechtes Chart: In VirtualBox mit Win7: Zeiten schwanken zuerst und fangen dann an zu wandern

GetTickCount64 gibt es in XE noch nicht, sonst hätte ich es ausprobiert
Bleibt für mich noch die Frage, was stimmt denn jetzt auf VirtualBox am genausten?
Ich werde noch manuelle Test mit einer Stoppuhr und ClickButton machen

Der aktuelle Code:

Delphi-Quellcode:

procedure TForm7.btStartClick(Sender: TObject);
begin
  iStartTickCount := GetTickCount;
  iStartPerfCount := GetTickStart;
  dtStartTime := now;

  tiTest.Enabled := not tiTest.Enabled;

  lsDelta.Clear;
end;

procedure TForm7.tiTestTimer(Sender: TObject);
var
  dtDeltaTime: TDateTime;
  iDeltaTickCount: Int64;
  iDeltaPerfCount: Int64;

  rDeltaSecTime, rDeltaSecTickCount, rDeltaSecPerfCount: Double;

begin
  dtDeltaTime := now - dtStartTime;
  iDeltaTickCount := GetTickCount - iStartTickCount;
  iDeltaPerfCount := GetTickDelta(iStartPerfCount);

  rDeltaSecTime := dtDeltaTime * 24 * 60 * 60;
  rDeltaSecTickCount := iDeltaTickCount / 1000;
  rDeltaSecPerfCount := iDeltaPerfCount / 1000;

  lsDelta.Add(rDeltaSecTime - rDeltaSecTickCount);
  lsDeltaQ.Add(rDeltaSecTime - rDeltaSecPerfCount);
end;

Damit die Ergebnisse zwischen altem und neuen Code vergleichbar sind, habe ich als Basis die Uhrzeit gelassen

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

[Ghostwalker]

Ok, das mit der Virtualisierung erklärt ein bischen was.

Wenn ich das mit der Virtualisierung (bin da soz. ein Noob) richtig verstanden hab, müssen die ganzen Aufrufe (QPC bzw. getTickCount) erstmal durch die Virtualisierungssoftware und dann ans Basis-BS geschleift werden. Das kostet natürlich Zeit, je nachdem was im Hintergrund vom Basis-BS noch läuft auch unterschiedlich lange.

Wenn ich mir die Charts aber so anschau, würd ich sagen ist QPC doch einiges genauer. Auch deine Aussage hinsichtlich, das die QPC - Werte sich auf einem Niveu einpendeln deutet darauf hin, das QPC hier die zuverlässigeren Werte liefert.

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

[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

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.
SetProcessAffinityMask oder 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. :stupid:

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.

[Uwe Raabe]

Zitat:

Zitat von norwegen60 (Beitrag 1463507)

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.

Also bei VMware gibt es eine Option Virtualize CPU performance counters. Könnte irgendwie damit zu tun haben.