Zitat:
Vor der Messung sollte die Priorität des Prozess auf TIME_CRITICAL gesetzt werden und danach natürlich wieder zurück. Ich habe festgesttelt, dass dies bei CPUID wohl nicht passiert, zumindest zeigt der Taskmanager nichts an in dieser Richtung.
Nein das ist nicht wirklich nötig. Es hängt nur von der verwendeten Methode der Zeitmessung ab.
Es gibt die absolute Messung und die relative Messung. Misst man zb. per einfachem Sleep(1000) so ist dies eine absolute Messung und bei dieser sollte man mit hoher Priorität messen. Nimmt man aber eine relative Messung, zb. RDTSC + PerformanceCounter dann x Millisekunden warten und dann wieder RDTSC + PeformanceCounter dann hat man qausi zwei unabhänig laufende Zeitbasen in Form von der Differenz in RDTSC und PerformanceCounter. Die Wartezeit zwischen den Messungen wird dann quasi irrelevant da beide Counter unabhängig vom Tasksheduller arbeiten. Davon abgesehen ist der Performancecounter weit genauer in der Auflösung als Sleep().
Ich hatte hier im Forum aber schon mal meine Messmethode erklärt und auch auf exakt diese Vorteile gegenüber Sleep() oder GetTickCount() hingewiesen.
Es sieht also so aus:
- man benötigt eine möglichst genaue und unabhängig laufende Zeitbasis, zb. der Peformancecounter läuft mit 1.6 MHz
- man führt nun eine Relativmessung durch
Code:
Basis := PerformanceCounter;
Messung := RDTSC;
warte par Millisekunden, könnte auch Sleep() sein, ist aber irrelavent
Basis := PerformanceCounter - Basis;
Messung := RDTSC - Messung;
Frequenz := Basis / PerformanceFrequency * Messung;
PerformanceFrequency ist meistens 1.6Mhz, also auf 1/1600000 Sekunde exakt. Sleep ist 1/1000 Sekunde exakt und der Tasksheduller funkt auch noch dazwischen.
Misst man mit der Relativmessung eine 3.2GHz CPU aus so wird man also auf +-2000 Taktzyklen exakt diese berechnen können. Mit Spleep()/GetTickCount im besten Falle auf +-3200000 Taktzyklen. Der Unterschied un der Genauigkeit beträgt also das 1600'fache.
Benutzt man Sleep() und TIME_CRITICAL Priorität so ist das kein Garant dafür das zb. Sleep(100) auch wirklich 100 Millisekunden dauert. Denn die Betriebsystemsoftware benötigt für das Sleep() selber immer auch einigen Overhead an zeit. Angenommen das wären bei Sleep(100) nur 1 Millisekunde mehr, also Sleep(100) dauert 101 Millisekunden so hat man bei 1 Sekunde Messdauer schon 10% Fehler drinnen. Eine 3.2GHz CPU würde also als 2.9GHz CPU gemessen.
Testet man Sleep(100) mit dem PerformanceCounter so wird man feststellen das auf den meisten CPUs das Betriebsystem eine feste Konstante als Overhead davon abzieht. D.h. Sleep(100) wird in den meisten fällen weniger als 100ms dauern. Ergo: eine darauf basierende CPU Frequenzberechnung wird die CPU Frequenz leicht überhöht ausrechnen.
RDTSC und der Peformancecounter sind in Hardware völlig unabhängig laufende Zähler/Timer. RDTSC hat die Frequenz zum aktuellen internen Takt der CPU. PerformaceCounter basiert auf der Realtimeclock im RTC BIOS Chip und läuft mit ca. 1.6MHz. In einigen Rechnern wird der PerformanceConterdurch das
OS aus dem RDTSC generiert. Dies wird dann auf Nootbook CPUs bzw. CPU's mit variable Taktanpassung zu Problemen führen.
Gruß Hagen