CPUiD 3.0 - Ein kleines System - Diagnoseprogramm

[himitsu]

@Luckie :
ich habe es mehrmals messen lassen und es ist definitiv keine der üblichen Schwankungen ... bei diesem Programm wird immer mehr angezeigt.

EVEREST: 1808.46 MHz - 1808.58 MHz
Hagen: 1808.79 MHz - 1808.81 MHz
dieses: 1812,9998 MHz

(wobei es mich hier wundert, daß es keine Differenz gibt, denn rein technisch geht es ja nicht ohne ein kleine Abweichung)

[stefan2005]

hi,
mein CPU wird zwar korrekt als "Athlon 64 X2 DualCore" erkannt, aber unter den AMD-Flags ist kein Häckchen bei "Dual-Core CPU" :lol:

mfg,
stefan

[MagicAndre1981]

Zitat:

Zitat von stefan2005

mein CPU wird zwar korrekt als "Athlon 64 X2 DualCore" erkannt

Das ist der Brand-String, den die BIOS-Programmieren festgelegt haben (ab dem AthlonXP steht der String nicht mehr fest bei AMD-Prozzis)

Zitat:

Zitat von stefan2005

, aber unter den AMD-Flags ist kein Häckchen bei "Dual-Core CPU" :lol:

weil sein Programm den Prozzi nicht kennt ;-)

[Daniel G]

Zitat:

Zitat von stefan2005

hi,
mein CPU wird zwar korrekt als "Athlon 64 X2 DualCore" erkannt, aber unter den AMD-Flags ist kein Häckchen bei "Dual-Core CPU" :lol:

Dann liegt das daran, dass der Flag, der normalerweise gesetzt ist, in deinem Falle aus irgendeinem Grund nicht gesetzt ist. Entweder hat scp das falsch implementiert, AMD hat den Flag verändert oder aber man hat dich verarscht.


@himitsu: Ja, das ist mir auch aufgefallen. Ich kanns leider nicht mehr ändern.

Mal sehen, eine komplette Neuauflage wäre vielleicht eine gute Idee für das neue Jahr.

I'll keep you posted!

[Ghostwalker]

Ok..im Anhang findest du die Daten, die Everest ausspuckt :)

[Thebe]

Bei meinem Sockel 478 Northwood wird kein L2 Cache von deinem Programm erkannt, obwohl Everrest da 512 KB zu sehen vermag. Ich häng ma komplett die HTML Datei von CPUiD und die Infos die Everest bei CPU und CPUID ausschmeißt per Anhang an.

Schickes Programm btw :)

- Thebe

[Daniel G]

@ Ghostwalker & Thebe: Danke für eure Dateien, ich arbeite jetzt tatsächlich an einer kompletten Neuauflage. Diesmal übrigens mit der VCL.

@All: Die Sache mit der Geschwindigkeit geht mir nicht mehr aus dem Kopf. Ich benutze folgenden Code, allerdings nicht selbst geschrieben:

Delphi-Quellcode:

//Helping Function for "GetCPUSpeed"
function ActivateTimer: Int64;
asm
   push   eax
   push    edx
   db      0fh
   db      31h
   mov      [esp], eax
   mov      [esp+4], edx
   pop      eax
   pop      edx
end;

// From "CPUID for Delphi" by Ural Gunaydin
function GetCpuSpeed(msTime: DWORD): Double;
var
   llStart, llStop: Int64;
   dwStart: DWORD;
   timecaps: TTimeCaps;
   bf1, bf2, minErr, tErr,
   ratio, bestRatio, bestBf: Double;
begin
   result:= 0.0;
   if (timeGetDevCaps(@timecaps, sizeof(TTimeCaps)) <> TIMERR_NOERROR) then
   Exit;

   timeBeginPeriod(timecaps.wPeriodMax);
   dwStart:= timeGetTime;
   llStart:= ActivateTimer;
   while ((timeGetTime() - dwStart) < msTime) do
   begin
      //
   end;
   llStop:= ActivateTimer;
   timeEndPeriod(timecaps.wPeriodMax);
   result:= (llStop - llStart) / msTime;

   bf1:= 1000*50.00000;
   bf2:= 1000*66.66666;
   minErr:= result;

   ratio:= Round(result / bf1);
   bestRatio:= ratio;
   bestBf:= bf1;
   tErr:= (ratio * bf1) - result;
   if (tErr  < minErr) then
   begin
      minErr:= tErr;
      bestRatio:= ratio;
      bestBf:= bf1;
   end;
   ratio:= ratio-1;
   tErr:= result - (ratio * bf1);
   if (tErr < minErr) then
   begin
      minErr:= tErr;
      bestRatio:= ratio;
      bestBf:= bf1;
   end;
   ratio:= Round(result / bf2);
   tErr:= (ratio * bf2) - result;
   if (tErr < minErr) then
   begin
      minErr:= tErr;
      bestRatio:= ratio;
      bestBf:= bf2;
   end;
   ratio:= ratio-1;
   tErr:= result - (ratio * bf2);
   if (tErr < minErr) then
   begin
      bestRatio:= ratio;
      bestBf:= bf2;
   end;
   result:= bestRatio * bestBf;
   //CpuInfo.CPUFreq:= result;
end;

Aufgerufen wird er mit:

Delphi-Quellcode:

something := Format('%.2f MHz', [GetCpuSpeed(1000) / 1000]);

Erkennt ihr irgendeinen Stolperstein?

[himitsu]

Was ich aber mal denken würde, ist daß in folgendem Code die Reinfolge der Timer nicht stimmt ... denn um die unterschiedlichen Start-/Endzeiten der einzelnen Timer zu vernachlässigen, müssen diese in der selben Reinfolge beendet werden, wie sie auch gestartet wurden.
(timeXXXPeriod und ActivateTimer direkt aufeinander folgend ... und timeGetTime innerhalb der Schleife)

Delphi-Quellcode:

timeBeginPeriod(timecaps.wPeriodMax);  <<<
llStart:= ActivateTimer;                       <<<
dwStart:= timeGetTime;
while ((timeGetTime() - dwStart) < msTime) do 
begin 
   // 
end; 
timeEndPeriod(timecaps.wPeriodMax);  <<<
llStop:= ActivateTimer;              <<<
result:= (llStop - llStart) / msTime;

Dann ist dein ActivateTimer etwas umständlich geschrieben.
(was aber zu keiner Messverfälschung führen wird ... jedenfalls, wenn die Timer in der richtigen Reinfolge gestartet/beendet werden)
Denn du holst dir den TSC-Wert, lädst diesen in den Stack und holst ihn zurück.
Aber wenn du genau hinsiehst, dann wirst du merken, daß sich nach dem Aufruf von RDTSC (DW $310F) die Werte in EAX und EDX nicht verändern.

Du lädst also z.B. EAX per mov [esp], eax in den Stack und holst ihn dann vom Stack wieder per pop eax in EAX zurück ... also "sinnloses" Hinundhergeschiebe.

Es würde also Folgendes vollkommen ausreichen:

Delphi-Quellcode:

function ActivateTimer: Int64; 
asm 
   db      0fh 
   db      31h 
end;

Und dann kannte ich deine MultimediaTimerFunktionen (timeBeginPeriod, timeEndPeriod) noch nicht ... weiß einer, wie genau die sind?
Und ob die Intern auch gleichschnell arbeiten und an der selben Stelle die Zeit messen, denn dieses könnte auch noch Fehler in die Gesamtmessung bringen.
Eventuell solltest du es mal mit einem Timer versuchen, bei welchem man die selbe Funktion für den Begin und das Ende der Messung verwenden kann ... z.B. QueryPerformanceCounter.


Und natürlich kann auch ein Fehler in der anschließenden Berechnung sein ... wozu soll daß denn eigentlich diehnen ... ich vermute ja dahinter mal die Tatsache, daß sich der Wert bei mehreren Messungen nicht ändert, denn es wird ja immer ein paar kleine Unterschiede geben, schon alleine dadurch, daß es sich um kein RealTimeSystem beim PC handelt und wie Luckie nachfolgend schon sagt, sich auch leicht andere Prozesse einschleichen und den Wert etwas verändern können.

[Luckie]

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.

[himitsu]

CPUID? ... du meinst wohl RDTSC (RealTimeCPUCounter)?

Und nein, da wird sowas nicht gemacht, der Befehl kopiert einfach nur den aktuellen Wert des RealTimeCPUCounter in EAX/EDX.

[Luckie]

Nein, ich meine CPUID, so heißt doch das Programm von Daniel oder? Und das scheint eben nicht die Prozesspriorität entsprechend zu setzen, das sollte man aber machen, um einen möglichst genauen Wert zu bekommen.

[himitsu]

ach stimmt ja, X'D
aber daß machen eh kaum jemand
und selbst Hagen (also auch ich) stellt das nicht extra um
und es funktioniert dennoch ^^

[Daniel G]

Zitat:

Zitat von Luckie

Nein, ich meine CPUID, so heißt doch das Programm von Daniel oder?

Ah, nicht ganz:

CPUiD

Man achte auf das kleine "i" in Anlehnung an mein Lieblings - Delphi - Forum. :zwinker:

Zum Geschwindigkeitsproblem:
Ich werde noch einige weitere Tests mit anderen Methoden machen. Woll'n wir mal sehen...

[negaH]

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

[Daniel G]

(Danke, Hagen :zwinker: )

Pre-Alpha Version 3.0

Um euch vorzuwarnen:
Bei dieser Version handelt es sich um eine absolut frühe Version, die noch nicht aus dem BETA - Stadium heraus ist. Einige Dinge müssen noch gefixt und implementiert werden.

Dazu gehören:

- Exceptionhandling
- Funktionstest unter Windows 9x
- "CPU - Cache" - Tab benötigt noch etwas Bearbeitungszeit
- Hilfe-Datei
- Report-Funktion
- Einstellungs-Dialog


Weiterhin gilt übrigens:

Das Programm benötigt keinen Treiber und keine Administratorrechte


Mal eine kleine Liste von Dingen, die neu sind:

Allgemein:
- GUI einer kleinen Schönheitskur unterzogen

Prozessorinformationen:

- Anzeige des FSB und des Multiplikators*
- Anzeige des Hersteller - Logos

Allgemeine Informationen(OS, Benutzername, Computername, System - UpTime)* (NEU)

Speicherinformationen(Bandbreite, Größe, Takt)* (NEU)


*Was genau an Informationen angezeigt wird, hängt von der SMBIOS - Version ab. Is' aber trotzdem 'ne dolle Sache :D

Download:
CPUiD PreAlpha 3.0 (~350 kb)
Screenshot (~60 kb)

[MagicAndre1981]

:shock: 4V Core-Spannung bei einem Athlon XP T-Bred-B :shock:

Ich glaub da stimmt was nicht :wink:

[Daniel G]

Zitat:

Zitat von MagicAndre1981

:shock: 4V Core-Spannung bei einem Athlon XP T-Bred-B :shock:

Ich glaub da stimmt was nicht :wink:

Let's burn that shit! :D

Aber komisch... Immerhin wirds bei mir korrekt angezeigt... Ich hole mir die Informationen nur via SMBIOS...

EDIT:
Welche SMBIOS - Version haddu denn?

[Basilikum]

irgendwo stimmt etwas nicht bei der Frequenz-Messung... die Messung dauert ziemlich exakt 30s, wobei der eine "CPU" zu 100% ausgelastet ist... (Pentium IV 2.8 GHz, Hyperthreading enabled)... FSB stimmt mit Angabe von CPU-Z überein...

[Daniel G]

In der Tat komisch, zumal, wie ich gerade sehe, weder der Benutzername noch der Computername ermittelt wird...

Bist du als Admin oder mit eingeschränkten Nutzerrechten angemeldet?

[Basilikum]

Zitat:

Zitat von Daniel G

In der Tat komisch, zumal, wie ich gerade sehe, weder der Benutzername noch der Computername ermittelt wird...

Bist du als Admin oder mit eingeschränkten Nutzerrechten angemeldet?

diese beiden Felder sind meiner Zensur zum Opfer gefallen... sie wurden einwandfrei ermittelt..... angemeldet bin ich mit lokalen Administratoren-Privilegien...

[Daniel G]

Zitat:

Zitat von Basilikum

Zitat:

Zitat von Daniel G

In der Tat komisch, zumal, wie ich gerade sehe, weder der Benutzername noch der Computername ermittelt wird...

Bist du als Admin oder mit eingeschränkten Nutzerrechten angemeldet?

diese beiden Felder sind meiner Zensur zum Opfer gefallen... sie wurden einwandfrei ermittelt..... angemeldet bin ich mit lokalen Administratoren-Privilegien...

Achso... Na dann.... :zwinker:

Taktet der P4 sich eigentlich herunter? Also sowas wie eine Stromsparfunktion? Dann könnte es evtl. daran liegen.

[Daniel G]

So, ich hab' mal 'ne neue Version hochgeladen. Exceptions werden jetzt nicht mehr abgefangen, ist zum Testen besser. Link ist der alte.

@Basilikum:
Kannst du's nochmal testen?


//Edit: Äh.. Ja, alle anderen dürfen und sollen natürlich auch testen :zwinker:

[MagicAndre1981]

Zitat:

Zitat von Daniel G

Welche SMBIOS - Version haddu denn?

Ich hab die Version 2.3.0.

[Daniel G]

Jupp, hab' ich auch, daran liegts also nicht. Merkwürdig... Und im BIOS wirds auch korrekt angezeigt, ja?

[MagicAndre1981]

Zitat:

Zitat von Daniel G

Jupp, hab' ich auch, daran liegts also nicht. Merkwürdig... Und im BIOS wirds auch korrekt angezeigt, ja?

Ja, aber die SMBIOS-Infos sind eh ungenau. Liegt wohl an ASUS, die da was verbockt haben.

[Basilikum]

Zitat:

Zitat von Daniel G

@Basilikum:
Kannst du's nochmal testen?

leider negativ - das selbe Verhalten wie vorher (EXE vom 2006-01-15 16:48 )

er bleibt in der Schlaufe zwischen dem 2. und 3. Aufruf von QueryPerformanceCounter für ca. 30s hängen (bzw. Live-Lock)....

[omata]

Hallo Daniel,

ich habe das selbe Problem wie Basilikum.

MfG
Thorsten

Edit:
Mir ist noch etwas aufgefallen...
Auf dem Reiter CPU - Flags(Intel)
Dort kann ich keinen Wert der Checkboxen verändern (das soll ja auch so sein) aber warum kann ich PSE - 36bit Page Size Extension verändern. Ist das so gewollt?

Edit2:
Auf dem Reiter BIOS, Speicher & RAM kann ich in einigen Label/Edit-Feldern etwas eintragen.

[Basilikum]

ich habe nun OllyDbg etwas beansprucht...

deine Routine:

Delphi-Quellcode:

Var
  F,
  X,
  C1,
  C2 : Int64;
Begin
  // dies und das

  QueryPerformanceFrequency(F);

  QueryPerformanceCounter(C1);

  // C2 := RDTSC

  X:= F * 2;
  while (X > 0) do Dec(X); // dies dauert sehr lange.... QPF liefert bei meiner CPU 2798720000 (= CPU Freq) zurück...
end;

[Daniel G]

Zitat:

Zitat von omata

Dort kann ich keinen Wert der Checkboxen verändern (das soll ja auch so sein) aber warum kann ich PSE - 36bit Page Size Extension verändern. Ist das so gewollt?

Nein, hab' ich schlicht vergessen. :stupid:

Zitat:

Zitat von omata

Auf dem Reiter BIOS, Speicher & RAM kann ich in einigen Label/Edit-Feldern etwas eintragen.

Öhm... Joar, hab' ich wohl auch vergessen... nee, nee, nee...

Zitat:

Zitat von Basilikum

ich habe nun OllyDbg etwas beansprucht...

deine Routine:

Delphi-Quellcode:

Var
  F,
  X,
  C1,
  C2 : Int64;
Begin
  // dies und das

  QueryPerformanceFrequency(F);

  QueryPerformanceCounter(C1);

  // C2 := RDTSC

  X:= F * 2;
  while (X > 0) do Dec(X); // dies dauert sehr lange.... QPF liefert bei meiner CPU 2798720000 (= CPU Freq) zurück...
end;

Wat? Hm... Das muss ich mir mal genauer ansehen. Das Interessante an der Sache ist, dass es nur bei Pentium 4 Prozessoren mit Hyperthreading auftritt...

[Luckie]

Beim Start:

Zitat:

---------------------------
CPUiD 3.0
---------------------------
'' ist kein gültiger Integerwert.
---------------------------
OK
---------------------------

Und auch beim Klicken auf aktualisieren.

Dem entsprechend kein Computername und kein Benutzername. Desweiteren meint dein Programm, mein System läuft schon über fünf Stunden. Vor fünf Stunden war ich aber bei meiner Freundin.
Unter RAM, BIOS, CPU Flags (AMD) ist auch alles leer.

Und die scrollenden Kredits würde ich erst starten, wenn der Tab ausgewählt wird, sonst landet man nämlich immer mitten drinne und das ist etwas blöd.

[Daniel G]

Zitat:

Zitat von Luckie

Beim Start:

Zitat:

---------------------------
CPUiD 3.0
---------------------------
'' ist kein gültiger Integerwert.
---------------------------
OK
---------------------------

Und auch beim Klicken auf aktualisieren.

Hmm... Liegt wohl daran, dass ich den Try..except - Block komplett entfernt hab'. :wall:

Zitat:

Zitat von Luckie

Desweiteren meint dein Programm, mein System läuft schon über fünf Stunden. Vor fünf Stunden war ich aber bei meiner Freundin.

Gegenfrage: Das ist nicht zufällig der Rechner mit diesem Problem, oder? Wenn ja, dann ist mein Programm unschuldig. :mrgreen:

Zitat:

Zitat von Luckie

Unter RAM, BIOS, CPU Flags (AMD) ist auch alles leer.

Liegt an der oberen Exception.

Zitat:

Zitat von Luckie

Und die scrollenden Kredits würde ich erst starten, wenn der Tab ausgewählt wird, sonst landet man nämlich immer mitten drinne und das ist etwas blöd.

Jupp, ich weiß. Über solche Kleinigkeiten wollte ich mich aber erst kümmern, wenns rund läuft.

[Daniel G]

Hmm... fassen wir mal zusammen:

Bei 4 Leuten (2 von silenthardware.de) gibt es dieses Problem mit der negativen bzw. zu geringen Taktfrequenz. Alle 4 nutzen einen P4, von 2 habe ich die Bestätigung, dass es sich um Prozessoren mit Hyperthreading handelt. Daran wird es wohl liegen.

Mal sehen, wie ich dieses Problem umschiffen kann. Hagen, weißt du 'ne Lösung? Ich nutze ja deine Prozedur, von daher...

//Edit

Zitat:

Zitat von MagicAndre1981

Zitat:

Zitat von Daniel G

Jupp, hab' ich auch, daran liegts also nicht. Merkwürdig... Und im BIOS wirds auch korrekt angezeigt, ja?

Ja, aber die SMBIOS-Infos sind eh ungenau. Liegt wohl an ASUS, die da was verbockt haben.

Hmm, Schade. Dann wäre mir ein eigener Fehler lieber...

[Luckie]

Zitat:

Zitat von Daniel G

Gegenfrage: Das ist nicht zufällig der Rechner mit diesem Problem, oder? Wenn ja, dann ist mein Programm unschuldig. :mrgreen:

Doch das ist er, aber davon sollte GetTickCount nicht betroffen sein, da GetTickCount die Anzahl der Millisekinden angibt, die seit dem Systemstart vergangen sind.

[Daniel G]

Zitat:

Zitat von Luckie

Doch das ist er, aber davon sollte GetTickCount nicht betroffen sein, da GetTickCount die Anzahl der Millisekinden angibt, die seit dem Systemstart vergangen sind.

Und wenn nun GetTickCount auch aus dem Takt geraten ist? Weil anders kann ich mir das nicht erkären...

[scp]

Zitat:

Zitat von MagicAndre1981

Zitat:

Zitat von Daniel G

Jupp, hab' ich auch, daran liegts also nicht. Merkwürdig... Und im BIOS wirds auch korrekt angezeigt, ja?

Ja, aber die SMBIOS-Infos sind eh ungenau. Liegt wohl an ASUS, die da was verbockt haben.

Das war vielleicht vor ein paar Jahren, mittlerweile sind sie recht genau, alle bei mir getesteten Systeme lieferten ordentliche Werte. Nur bei [System Information], [Base Board (or Module) Information], [System Enclosure or Chassis Information] und gelegentlich auch [Port Connector Information] gibts Lücken, diese sind aber auch nicht so wichtig. Bei den ersten dreien wird meist für OEMs Platz gelassen.

[Basilikum]

Zitat:

Zitat von Daniel G

Hmm... fassen wir mal zusammen:

Bei 4 Leuten (2 von silenthardware.de) gibt es dieses Problem mit der negativen bzw. zu geringen Taktfrequenz. Alle 4 nutzen einen P4, von 2 habe ich die Bestätigung, dass es sich um Prozessoren mit Hyperthreading handelt. Daran wird es wohl liegen.

dies hat vermutlich mit der Art und Weise zu tun, wie der/das HT-HAL die QueryPerformance(Frequency|Counter) implementiert....

da es mich nun doch auch wunder nimmt, ein Quick-n-Dirty-Ansatz zum Ermitteln der CPU-Clock-Rate...

funzt einwandfrei auf folgenden Systemen:

Pentium III 500 MHz, WinXP
Pentium IV 2.8 GHz (HT), WinXP
Pentium IV 3.0 GHz (HT), Win2k3
Dual Pentium II 350 MHz, WinNT4
Celeron 735 MHz, WinNT4
Pentium II 333 MHz, WinNT4

(Angabe stimmt jeweils mit CPU-Z überein)

Delphi-Quellcode:

// siehe übernächsten Post

[negaH]

@Basilikum:

das was du da machst ist wieder eine Absolutmessung die ungenau sein wird. Nur diesesmal wird in der Wartschleife nicht per Sleep(x) X Millisekunden gewartet sondern eben PerformanceFrequency / 8 Takte lang gewartet.

Was passiert aber während dieser Schleife im restlichen Teil deines Rechners ? Dort laufen Interrupts, andere Processe, Kernel Task mit hohen Prioritäten ab. D.h. wenn deine Schleife PerformanceFrequency / 8 Takte dauern soll so wird sie dies niemals können da dein Code nich sicherstellen kann das aer der EINZIGSTE im gesammten System ist der zu diesem Meßzeitpunkt ausgeführt wird !

So wäre es richtiger

Delphi-Quellcode:

  C1 = RDTSC;
  C2 = PerformanceCounter;

  Sleep(x);

  C1 = RDTSC - C1;
  C2 = PerformanceCounter - C2;
  
  F = C2 / PerformanceFrequency * C1;

Egal was nun alles im Sleep(x) passiert und wie lange diese Wartezeit dauert wir benutzen zwei zueinandner absolute Hardwarecounter. Den RDTSC der die Anzahl der Takte der CPU ermittelt und den "Maßstab" über den PeformanceCounter bei dem wir über PerformanceFrequency auch dessen Auflösung ermitteln können.

Das Verfahren ist als echt simpel. Du hast zwei Uhren. Die eine Uhr misst in einer uns bekannten Genauigkeit, zb. 1 Sekunde. Die zweite Uhr können wir ablesen aber wir wissen nicht ihre Auflösung/Genauigkeit. Wir starten nun beide Stopuhren synchron, warten eine gewissen Zeit (mindestens > Auflösung unserer Refernezuhr, also hier > 1 Sekunde). Wir wissen dann also das die Zweite Uhr zb. in 10 Sekunden exakt 500 Schritte weitergezählt hat. Also dividieren wir 500 / 10 Sekunden und kommen so auf den Sekundentakt der zweiten Uhr von 50, eg. 50 Hz.

In diesem Moment ist es nun egal ob wir 10 Sekunden lang messen oder 100 Sekunden oder nur Millisekunden lang. Wir sind also komplett unabhängig vom restlichen Betriebsystem oder anderer Sofwtare da wir ja beide "Uhren" in Hardware vorliegen haben.

Gruß Hagen

[Basilikum]

@Hagen:
ich sehe gerade, zur späten Stunde haben meine Finger nicht das implementiert, was ich mir im Kopf vorgestellt hatte......... :oops:

eigentlich wollte ich es so (MinPerformanceCounter habe ich nächtens etwas übereilig wegoptimiert):

Delphi-Quellcode:

Var
  PerformanceFrequency,
  ClockCounter1,
  ClockCounter2,
  PerformanceCounter1,
  PerformanceCounter2,
  MinPerformanceCounter : Int64;
begin
  SetThreadAffinityMask(GetCurrentThread(),1);

  QueryPerformanceFrequency(PerformanceFrequency);

  QueryPerformanceCounter(PerformanceCounter1);
  ClockCounter1:=RDTSC;

  MinPerformanceCounter:=PerformanceCounter1 + (PerformanceFrequency div 8);

  // hier könnte man noch diverse andere Dinge erledigen... Zeitverbrauch spielt keine Rolle - Messung würde sogar eher genauer

  Repeat
    QueryPerformanceCounter(PerformanceCounter2);
  Until (PerformanceCounter2 >= MinPerformanceCounter);

  ClockCounter2:=RDTSC;

  WriteLn((ClockCounter2 - ClockCounter1) / ((PerformanceCounter2 - PerformanceCounter1) / PerformanceFrequency) / 1000000000:1:4,' GHz');
end.

eigentlich deinem Vorgehen recht nahe, ausser dass ich die CPU während der Schlaufe künstlich beschäftigt halte (damit er nicht plötzlich aus langeweile irgend welche Pausen einlegt und nicht die volle Takt-Zahl gemessen wird)...

das einzige - jedoch unlösbare - Problem ist, dass man die beiden Operationen "RDTCS" und "QPC" nicht atomar durchführen kann... sobald sich ein anderer Thread zwischen diese beiden Operationen schiebt, entstehen Fehler...

[Daniel G]

Soo... Ich hab' mal deine obige Erweiterung eingebaut, Basilikum. Ich hoffe mal, dass es jetzt keine Probleme mehr mit HT - Prozessoren gibt.

[mirage228]

Hi,

Bei mir der Wert von meinem Prescott 640 nun korrekt mit ~3211,44 Mhz beziffert :)

Ansonsten scheinen die anderen Werte auch zu stimmen :)

mfG
mirage228