CPUiD 3.0 - Ein kleines System - Diagnoseprogramm

[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