High performance counter

08/11/2007 - 03:35 von Ulrich Korndoerfer | Report spam
Weil ich neulich drüber gestolpert bin und es vielleicht noch nicht
jeder mitgekriegt hat:

Auf neueren PCs unter neueren Betriebssystemen ist die Auflösung des
High Performance Counters *gewaltig* angewachsen!

So hatte mein altes System (PIII 550MHz, WIN 2K) eine
QueryPerformanceFrequency von (weiß nicht mehr genau) ca. 1-10 MHz.

Bei Win XP SP2 und Intel CoreDuo2 meldet der jetzt die CPU-Taktfrequenz!
Das sind bei mir um die 2 GHz! Das ist eine Zeitauflösung von einer
halben Nanosekunde! Eine Long ist also nach ca. 2 Sekunden voll.

Generell gibt das sicher bei den Einem oder Anderen von Euch Probleme,
wenn die TickCounts nun ca. 2000 mal so schnell ticken.

Verwendet man zB. zum Auslesen von QueryPerformanceCounter (wie üblich
unter VB) eine Currency und multipliziert den erhaltenen Tickcount mit
10000 (um auf Sekunden zu skalieren), gibt das bei lànger andauernder
Uptime des Rechners (bei mir waren es über 2 Monate, kann man aber
leicht ausrechnen, wanns kritisch wird) einen Überlauf! Ebenso kann man
die Tickcounts dann nicht mehr ohne Auflösungsverlust in eine Double
umwandeln.

Außerdem scheint es zu sein, daß die QPC Abfragen nicht mehr so spinnen
wie früher (ist aber noch genauer zu testen).

Jedenfalls war es früher so, daß, wenn man nur schnell genug hàufig
genug den QPC in einer engen Schleife abgefragt hat, von Abfrage zu
Abfrage der TickCount plötzlich um einiges größer war (wesentlich größer
als die real vergangene Zeitspanne zwischen den Abfragen).

:-)

Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
 

Lesen sie die antworten

#1 Schmidt
08/11/2007 - 16:07 | Warnen spam
"Ulrich Korndoerfer" schrieb im
Newsbeitrag news:%23qa85$

Verwendet man zB. zum Auslesen von
QueryPerformanceCounter (wie üblich
unter VB) eine Currency und multipliziert
den erhaltenen Tickcount mit
10000 (um auf Sekunden zu skalieren), ...


Warum sollte man das tun?
Wenn man sich mittels QueryPerformanceFrequency
die Frequenz ebenfalls in einen Currency holt,
dann muss man nicht multiplizieren - man darf
dann direkt teilen:
Dim curFreq as Currency, curCounter as Currency
QueryPerformanceFrequency curFreq
QueryPerformanceCounter curCounter
Dim HighResDblResultInSeconds as Double
HighResDblResultInSeconds = curCounter / curFreq

Ich komme auf die Art, selbst bei 3GHz CPU-Freq
auf eine Rechner-Uptime von ca. 100 Jahren
(und ohne das letzte Bit vom Currency auszunutzen).
?2^63 / (3e9#*3600*24*365) = 97,49 'Jahre

Außerdem scheint es zu sein, daß die QPC
Abfragen nicht mehr so spinnen
wie früher (ist aber noch genauer zu testen).


Die Hersteller tun was bei ihren CPU-(ACPI)Treibern,
um auch beim Switching von Thread-Kontexten
von einem CPU-Core auf den anderen stabile
Frequenz Daten zu liefern - aber so richtig trau
ich dem Frieden da nicht.
Verlàsslicher als das Abfragen der CPU-Frequenz
sind immer noch die alternativen Timer.
Das QueryPerformance-API greift leider nicht
durchgàngig auf die stabileren (weil CPU-unabhàngig
tickenden) Hardware-Counter zurück wie z.B. den:
PIT (QueryPerformanceFrequency = 1193182 Hz)
oder
ACPI PMT (QueryPerformanceFrequency = 3579545 Hz)

Stattdessen benutzt die Implementierung (nach welchen
Kriterien auch immer) inzwischen gerne den TSC
(also die CPU-Clock).
Die Wine-Implementierung auf Linux vermeidet z.B.
den TSC (an die unterschiedlichen "Strom-Spar-Frequenzen"
und die Multicores denkt bei MS offenbar keiner).
Zumindest bietet Microsoft die Option, dem Kernel beim
Booten mitzuteilen, dass er doch bitte den ACPI-PMT
benutzen soll (wàre dann der /usepmtimer - switch).

Jedenfalls war es früher so, daß, wenn man nur schnell
genug hàufig genug den QPC in einer engen Schleife
abgefragt hat, von Abfrage zu Abfrage der TickCount
plötzlich um einiges größer war (wesentlich größer
als die real vergangene Zeitspanne zwischen den Abfragen).


Gab früher mal (Bus-)Probleme mit den Hardware-Anfragen
an die alternativen Timerchips auf den Motherboards.
Zu genau der Zeit gab es aber noch keine MultiCores
und auch keine StepDown-Stromsparfunktionen in den
gàngigen CPUs. Kann gut sein, dass MS deshalb den TSC
innerhalb seiner QPF-API-Implementierung pràferiert hat.
Inzwischen ist die Lage aber genau wieder andersherum.
Die Hersteller haben ihre Motherboard-Chipsàtze im
Griff (zumindest die TimerChips) - stattdessen ist man jetzt
mit schwankenden CPU-Frequenzen konfrontiert.
Zeit, dass wieder umzuswitchen in irgendeinem SP - (der
boot.ini-Switch zeigt doch, dass das kein Problem ist)
Aber möglicherweise hat der Vista-Kernel ja schon entspr.
Updates in der Richtung bekommen.

Olaf

Ähnliche fragen