CPUiD 3.0 - Ein kleines System - Diagnoseprogramm

[Daniel G]

Juchuhh...

Dann kann ich mich endlich um all' die anderen kleinen Details kümmern.

[Luckie]

Also bei mir kommt immer noch

Zitat:

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

[Basilikum]

Zitat von Daniel G:

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

jep... jetzt startet das Tool angenehm schnell (< 1 sec) und die CPU-Frequenz stimmt !

[omata]

Ja, jetzt geht es auch bei mir. super!

Habe aber nochwas gefunden:
Auf dem Reiter BIOS, Speicher & RAM und dort Art des Slots: kann ich immer noch editieren.

MfG
Thorsten

[Daniel G]

Zitat von Luckie:

Also bei mir kommt immer noch

Zitat:

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

War ja klar

Sind die anderen Felder auch noch leer?
kannst du mir mal 'nen Screenshot zeigen, damit ich sehen kann, welcher Wert die Ursache sein könnte?


@Basilikum: Danke

[Luckie]

Kommen.

[turboPASCAL]

Da der Rechner von Luckie gesagt hat das '' ist kein gültiger Integerwert ist wollte ich das mal auf meinem Rechner überprüfen und musste feststellen dass das nicht simmt, denn bei mir kommt kein Fehler, also muss "" ein gültiger Integerwert sein.

Keine Fehler gefunden (bis auf das editieren). Ich hätte aber gern noch eine Gesamtsumme des Arbeitsspeichers auf einen Blick.

[Daniel G]

Zitat von turboPASCAL:

Da der Rechner von Luckie gesagt hat das '' ist kein gültiger Integerwert ist wollte ich das mal auf meinem Rechner überprüfen und musste feststellen dass das nicht simmt, denn bei mir kommt kein Fehler, also muss "" ein gültiger Integerwert sein.

Hä?

Zitat von turboPASCAL:

Ich hätte aber gern noch eine Gesamtsumme des Arbeitsspeichers auf einen Blick.

Lässt sich einrichten.

//Edit:
Ähhh.... Das wird doch schon angezeigt. Siehe Anhang, rot eingerahmt.

@Luckie:
Liegt wohl daran, dass der FSB nicht ermittelt werden kann. Ich check das mal...

[negaH]

Zitat von Basilikum:

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...

Es ist exakt das was ich vorschlug

Unlösbar ist relativ zu sehen. Wichtig sind zwei Dinge:

1.) die beiden Aufrufe RDTSC + PerformanceCounter müssen exakt synchron sein, d.h.

Delphi-Quellcode:

1.)
    C1 := RDTSC;
    C2 := PerformanceCounter;

2.)
    C3 := RDTSC;
    C4 := PerformanceCounter;

3.)
    F := (C3 - C1) / (C4 - C2) * PerformanceFrequency;

die Sourcezeilen 1.) und 2.) müssen exakt identisch sein, gleiche Reihenfolge der Aufrufe und sollten wenn es möglich wäre per CLI/STI geschützt werden.

2.) geht man nun rein statistisch vor so können bei beiden Aufrufen irgendwelche Ereignisse des OS dazwischenfunken exakt zwischen RDTSC und PerfoemanceFrequency. Da wir aber bei Punkt 1.) und 2.) exakt die gleiche Codesequenz benutzen ist bei beiden Sequenzen die Wahrscheinlichkeit für eine Störung exakt gleich. Wenn also bei Sequenz 1.) zb. 50% Wahrscheinlichkeit beträgt so beträgt die Wahrscheinlichkeit -50% das bei 2.) die gleiche Störung auftritt. Somit gleicht sich ein Meßfehler bei 1.) durch den Meßfehleer bei 2.) wieder aus. Der Grund für diese "gleichverteilte" Wahrscheinlichkeiten liegt in der Arbeitsweise unserer Rechner. Sie sind exakt Taktbasiert, sehr periodisch und sehr statistisch gleichverteilt.

Ergo: die resultierende Genauigkeit der Meßmethode ist bei weitem ausreichend wenn man bedenkt das der PerformanceCounter mit 1.6 MHz Auflösung läuft.

Als Meßverzögerung in Sleep(x) reicht 1 Millisekunde aus. Die Dauer dieser Zeitverzögerung hat dabei nur einen sehr unwesentlichen Einfluß auf die erreichte Genauigkeit. D.h. ob man beim Sleep(x) 1 Sekunde wartet oder nur 1 Millisekunde lang wird nur die Meßdauer verändern nicht das Resultat ! Ergo ist es mit dieser Methode nicht nur exakter sondern man kann auch die Meßzeit enorm verkürzen.

Ausreichend dürfte eine Meßdauer von 1 / PerformanceFrequency * 2 sein, da das Abtasttheorem (Nyquist) dies dikiert.

Ich benutze immer folgendes

Delphi-Quellcode:

  Tick := GetTickCount +1;
  while Tick <= GetTickCount do 
    Sleep(0);

Dies dauert dann schon 800 mal länger als erforderlich. Das Sleep(0) erzwingt einen Taskswitch und sollte immer vor der Messung an Punkt 1.) und 2.) durchgeführt werden. Das liegt an der Arbeitsweise des Taksshedullers. Wechselt dieser von einem Taks zu einem anderen Task so stellt dieser sicherer das der neue aktive Task eine Mindestausführungszeit bekommt. Diese Ausführungszeit ist weit länger als die Aufrufe des RDTSC und PeformanceCounter ansich benötigen. Ergo, nachdem Sleep(0) in unseren Code zurückkehrt können wir zeimlich sicher sein das die nachfolgenden zwei Sourcezeilchens nicht extern unterbrochen werden. (Außnahmen sind Ring0 und Interrupts, die beide aber wieder hoch periodische Ereignisse sind).

Gruß hagen

[turboPASCAL]

Zitat von Daniel G:

Zitat von turboPASCAL:

Ich hätte aber gern noch eine Gesamtsumme des Arbeitsspeichers auf einen Blick.

Lässt sich einrichten.

//Edit:
Ähhh.... Das wird doch schon angezeigt. Siehe Anhang, rot eingerahmt.

Stimmt... ja. Das es nicht unter "RAM" steht hat mich wohl etwas verwirrt