exakte Zeitmessungen auf Multiprozessoren

[negaH]

Hi Leute,

heute musste ich erstaunt feststellen das meine Zeitmessroutinen/Taktanzahlmessungen auf einem Intel Duo Core Laptop total falsche Ergebnisse liefern. Ich hatte mich schon damit abgefunden das zb. meine Pi Berechnungen auf einem Core Duo 2.16Ghz Laptop nur 4 mal schneller sind als auf einem P4 1.5Ghz Rechner. Das heist das mein Laptop nur 4 mal schneller ist und nicht mehr Power hergibt.

Jetzt musste ich aber feststellen das es garnicht an dem ist, sondern das meine Zeitmessungen falsche Ergebnisse liefert. Es scheint nun wohl so zu sein das auf dem Laptop die Berechnungen ca. 12 mal schneller sind, was mich natürlich freut, da ich nun einen Rechner habe der innerhalb der letzten Stunde drastisch schneller geworden ist

Ok. Meine Messroutinen arbeiten mit dem Real Time Counter -> RDTSC. Um dessen Werte in Zeiten umrechnen zu können messe ich mit QueryPerformanceCounter()/Frequency() quasi die Taktfrequenz der CPU aus. RDTSC liefert ja nur die CPU Takte zurück und zb. keine Millisekunden.

Nun, das Ausrechnen dieser Taktfrequenz scheint wohl auf Multiprozessoren nicht ganz trivial zu sein. Besonders weil ja auf Laptops zusätzlich noch das ACPI dazwischen funkt und den Prozessortakt variabel einstellen kann.

Gut, ich weis das man mit GetTickCount() auf der sicheren Seite ist, allerdings ist dessen Auflösung eben nicht berauschend. Ich würde also ungern auf RDTSC verzichten, benötige dann aber auch eine exakte Umrechnung von RDTSC in Zeit.

Hat einer von euch eine Idee, Source oder Hinweise wo ich suchen könnte ?
Und als zweite Frage: kann es sein das das ACPI beide Prozessoren unterschiedlich in der Taktfrequenz drosseln kann ?

Gruß Hagen

[supermuckl]

ich hab das gleiche problem mit dem queryperformancecounter dingens.
meine zeitberechnung zeigt teilweise sogar negative werte an, wenn ich die zeit zwischen 2 befehlen messen will, die dort vergangen ist!!

ich bin mit meinem latein am ende.

gettickcount ist mir auch zu ungenau
und der dx-timer zu ressourcenintensiv

[St.Pauli]

Das scheint nicht nur dir so zu gehen. Das Problem müssen auch viele andere Programme (z.B. Spiele) haben die QueryPerformanceCounter und QueryPerformanceFrequency verwenden.

Zitat von Microsoft:

While the QueryPerformanceCounter / QueryPerformanceFrequency API is intended to be multiprocessor aware, bugs in the BIOS or motherboard drivers may result in these routines returning different values as the thread moves from one processor to another.

http://www.gamedev.net/community/for...opic_id=409541

http://support.microsoft.com/kb/909944

Ein AMD-Schreiben

Was ich herausgelesen habe ist, dass es auch helfen kann wenn man die neusten Treiber von AMD oder Intel installieren sollte.

[Muetze1]

Das grunglegende Problem ist der mehrfache Taskswitch pro Sekunde und dein Task wird auch frei von einem Kern auf den anderen verschoben. Wenn ein Kern mal öfters im Halt war oder mehrfach die Taktfrequenz änderte, dann gehen die Time Stamp Counter der beiden Kerne auseinander, da einer weniger Taktimpulse hatte als der andere. Da nun der Thread/Prozess mehrfach zwischen den Kernen wechselt, ist die wahrscheinlich hoch, dass man auf einem Kern den Counter liest (Startpunkt) und auf einem/dem anderen Kern den Counter beim Stoppen. Und so einfach kann die Zeit auch mal negativ sein.

Abhilfe würde hier z.B. das Festlegen eines Threads/Prozesses auf einen logische CPU/Kern helfen. Dies schliesst das beschriebene aus, aber nicht die Nebenwirkungen des Power/Taktmanagements.

SetThreadAffinityMask(), SetProcessAffinityMask(), etc ...

So, Details und weitere Info's in den über mir verlinkten Links..

[negaH]

Naja, das ist nicht so trivial wie es sich anhört.

Ich messe ja nicht mit QueryPerformanceCounter() sondern die CPU Takte mit RDTSC -> Time Stamp Counter.

Das sieht dann ungefähr so aus:

1.) Kalibration

- ermittelle die RDTSC Takte für eine beliebige Zeitdauer X (zb. 10ms)
- ermittelle parallel dazu mit QueryPerrformanceCounter() einen Start und Stop Wert
- man hat nun 2 Differenzwerte: 1.) Anzahl der CPU Takte der Messschleife und 2. Anzhal der Takte relativ zu PerformanceFrequency()
- am Schluß kann man mit RDTSC_Takte / Performance_Takte * Peormance_Frequency also die Taktfrequenz der CPU ermitteln.
- dieser Wert wird global gespeichert

2.) Messung

- lese Time Stamp Counter mit RDTSC
- führe zu messende Funktionen aus
- lese Time Stamp Counter mit RDTSC und bilde Differenz, also die Anzhal der CPU Takte der ausgemessenen Funktion

3.) Umrechnung
- dividiere obige errechnete CPU_Frequency durch RDTSC_Takt_Anzhal_gemessen und je nach gewünschter Zeitskale multpliziere es zb. mit 1000 um Millisekunden zu haben

Dh. alle meine Messungen messen nur die CPU Takte aus und rechnen das am Schluß erst auf Zeit um.

Wenn aber die Taktfrequenz einer CPU nicht mehr konstant ist, also variabel mit der Zeit durch das ACPI angepasst werden kann, dann gibt es keinen Weg irgendwelche genaue Messungen durchzuführen, zumnindestens mit dem Time Stamp Counter.

Schätze mal das GetTickCount() wirklich die einzigste Alternative ist, der Time Stamp Counter ist auf alle Fälle unbrauchbar geworden.

Gruß Hagen

[Amateurprofi]

Hallo Hagen,

ich benutze zum Zeitmessen auch nur RDTSC, und die Kalibrierung mache ich auch so wie Du.
Allerdings habe ich bemerkt, daß bei sehr kurzen Kalibrierungszeiten (Du erwähntest 10 ms) die Ergebnisse (RDTSC-Ticks/Sekunde) weit weg waren von der "tatsächlichen" Frequenz. Als optimale Zeitspanne habe ich 200 ms gefunden.

Delphi-Quellcode:

FUNCTION TimeStamp:Int64;
asm
   rdtsc
end;

FUNCTION TimeStampFrequency:int64;
var oldpriority:word;  q0,q1,qf,ts0,ts1:int64; seconds:extended;
begin
   oldpriority:=GetThreadPriority(GetCurrentThread);
   SetThreadPriority(GetCurrentThread,THREAD_PRIORITY_TIME_CRITICAL);
   QueryPerformanceCounter(q0);
   ts0:=TimeStamp;
   Sleep(200);
   ts1:=TimeStamp;
   QueryPerformanceCounter(q1);
   SetThreadPriority(GetCurrentThread,oldpriority);
   QueryPerformanceFrequency(qf);
   seconds:=(q1-q0)/qf;
   result:=Trunc((ts1-ts0)/seconds+0.5);
end;

[marabu]

Hallo Hagen,

es gibt einen interessanten Artikel von Chuck Walbourn im MSDN zu diesem Thema: Game Timing and Multicore Processors.

Grüße vom marabu

[negaH]

@Klaus:

Zitat:

....der "tatsächlichen" Frequenz. Als optimale Zeitspanne habe ich 200 ms gefunden.

Das lässt sich exakt ausrechnen. Die minimale Zeitspanne der "Zeitschleife" sollte min 2 mal so groß sein das wir alle Takte der Refrerenzfrequenz abgearbeitet haben. In unserem Falle also QueryPerformanceFrequency() * 2. Wenn diese Funktion intern auf die Time Stamp Counter geht sollte man also ca. 2 Sekunden warten, da diese Funktion ja dann die CPU Frequenz in Hz angibt und das ist auf 1 Sekunde bezogen. Der Faktor 2 erklärt sich auf Grund des Nyquist Theorems, das auch auf unseren Kalibrierungsprozess wirkt. Sollte QueryPerformanceFrequency() aber wie auf meinem P4 nur ca. 3.6MHz groß sein, die CPU aber mit 1500MHz getaktet werden , so sollte man ca. 3.6 / 1500 * 2 = 4.8 Millisekundewn lang messen. Länger macht keinen Sinn da die maximale Genauigkeit damit schon erreicht wurde.

Da wir ja mit RDTSC und QueryPerformaceCounter() in parallel messen und beide Timer unabhängig vom BIOS, OS usw. laufen sollten (auf SingleCPU ohne ACPI ist das noch korrekt) müssen wir uns um die Thread/Process Prioritäten, dem Tasksheduller usw. überhaupt nicht kümmern. Denn die Wartezeit im Sleep(xyz) könnnte nur größer werden aber niemals kürzer als die minimale Zeit die wir ja vorgeben. Und ansonsten benötigen wir das Sleep() ja eben nicht direkt für unsere Messung, eine Schleife mit GetTickCount() oder sonstwas anderes was minimal QueryPerformanceFrequency() *2 lang andauert hätte es auch getan.

Ergo: ob du im Sleep() 10ms oder 200ms angibts ist auf Grund der differientiellen Kalibrierungsmethode irrelevant. Wir benötigen das Sleep() ja nur damit unserer beiden Timer eine minimale Zeitspanne von > 5ms bekommmen.
Die Prioritäten des Prozesses/Threads zu erhöhen ist Quatsch und verändert garnichts, da wir ja eben eine Differientielle Kalibrierung mit zwei vom OS unabhängigen Timern machen.

So, aber wie es sich nun herausstellt gilt auf neuerer Hardware folgendes:

1.) RDTSC ist abhängig vom CPU Takt und dieser kann fließend und variabel in der Zeitachse durch das Power Management System ACPI einestellt werden. Gerade auf Laptops der Fall.

2.) die PerformanceCounter() benutzen selber RDTSC, sehr ungünstig für unsere Kalibrierung

3.) auf Multiprozessoren können die CPUs unterschiedliche im Takt eingestellt werden was dazu führt das die RDTSC Counter sogar asynchron zueinander sind, jeder CPU Kern hat ja einen eigenen RDTSC und auch Takt

4.) das Windows OS benutzt in QueryPerformanceCounter() die RDTSC und während einer Messung kann die Affinitäten eines Threads zu der CPU sich ändern. Dh. dieser Thread wird teilweise auf der 1. CPU und später auf der 2. CPU ausgeführt. Das Windows OS API für QueryPerformanceCounter() benutzt aber immer nur die RDTSC Counter der zum Aufruf der API Funktion gültigen CPU zum Thread. Das Windows API ist in diesem Falle also eine Fehlkonstruktion.

Ergo beides, RDTSC und QueryPerformanceCounter() sind aus ganz unterschiedlichen Gründen absolut untauglich geworden, sie sind eben nicht mehr unabhängige Timer vom OS/BIOS etc.pp. Eine korrekte Berechnung einer Messschleife benötigt eine Formel die gleich mindestens 3 variable Unbekannte involviert. Diese 3 Unbekannten sind auf der Zeitachse veränderlich und sind

1.) unterschiedlicher CPU Takt der einzelnen CPU Kerne, die RDTSC laufen unterschiedlich schnell
2.) QueryPerfromanceCounter() benutzt selber RDTSC, nicht mehr den Timer Chip des BIOS
3.) der Tasksheduller bzw. die Affinitäten der Threads zu verschiedenen CPUs

Diese Formel dürfte ohne klare Unterstützung der CPU, BIOS, OS Hersteller nicht zu lösen sein. Das Microsoft das Problem auf die CPU/BIOS Hersteller abschiebt ist ebenfalls nicht korrekt.

Ich baue alle meine Routinen auf GetTickCount() um, da weis ich was ich habe. Die Lösung von MS oder BIOS muß es sein einen hochauflösenden externen Timer als API zur Verfügung zu stellen. Dieser Timer muß eine Absolutzeit zurückgeben, denn was nützt uns eine "Zeitmessung" deren Takt sich variabel verändert ?! Das ist hirnrissig.

Gruß Hagen

[negaH]

Es ergeben sich aber auch andere Vorteile bzw. Möglichkeiten

Man kann RDTSC dazu benutzten um die RMS Auslastung der CPUs zu messen. Auf meinem Laptop zb. ergaben sich für die gleiche zu messende Funktion folgende Zeiten

1.) 12 sec
2.) 4 sec

Das zeigt uns das die 2. Messung auf einer CPU lief die 3 mal schneller getaktet wurde als bei der 1. Messung. Man könnte also eine TrayIcon APP bauen die für jede CPU die aktuelle Taktfrequenz anzeigt. Nun kann man dies PI*Daumen umrechnen in Stromverbrauch, denn bei CMOS ist es so das quasi nur die Taktfrequenz die Stromaufnahme bestimmt.

Gruß Hagen

PS: Marabu, danke für den Link, ich hätte mir mein Palaver oben sparen könne

[Olli]

Wenn du keine Gleitkomma-Ops benutzt, kannste deine Berechnung ja in den Kernelmode verlegen und bei gehaltenem Spinlock (nicht auf Checked Versions machen ) tätigen. Das System reagiert dann zwar solange nicht mehr, bis die Berechnung fertig ist und sie läuft auch nur auf einer CPU, aber ansonsten ist alles fit. Ach ja ... wenn du den FPU-Status vorher sicherst, kannste natürlich auch mit FPU-Ops "rummachen"