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"

mfg,
stefan

[MagicAndre1981]

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 von stefan2005:

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

weil sein Programm den Prozzi nicht kennt

[Daniel G]

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"

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:

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.