CPUiD 3.0 - Ein kleines System - Diagnoseprogramm

[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