Seite 2 von 3
Verfasst: 12.03.2005 22:41
von MVXA
Kaeru Gaman hat geschrieben:MVXA hat geschrieben:und wenn er die Demo hat, bzw. die APIs noch nicht von Fred eingebunden wurden? Gibt es -_-.
Ich schreib es ma so um:
Die APIs noch nicht von Fred für PB nativ aufrufbar inportiert hat.
Verfasst: 12.03.2005 22:53
von Froggerprogger
@Laurin
Ich habe obigen Code erweitert und 'härtere Bandagen' aufgefahren. (API-calls und Realtime-Priority)
Klappt das nun ?
Ansonsten müßte ich passen.
Hast Du es denn auch mal mit 1 sec Testphasenzeit probiert ?
Vielleicht 'beschleunigt' deine CPU während des Tests, falls sie zuvor auf langsam eingestellt war, so dass man den Test über längere Zeit ausführen muss, oder besser noch, zweimal direkt nacheinander, und nur das zweite Ergebnis zählen.
Wer misst misst Mist. Erst recht wohl bei veränderbaren Taktraten.
Verfasst: 13.03.2005 01:00
von Laurin
Mit dem neuen Code Code zeigt er meist die aktuelle Taktrate an also 1 Ghz. Jedoch schwankt der Wert immernoch. Ich hatte nach mehreren Testläufen, 0,99 Ghz, 1,0-irgendwas und 1,7 Ghz. Ich habe es auch mit längeren Zeiten probiert (10 Sek.).
Wenn ich mir so einige Programme anschaue (zB DirectX-Kontrollprogramm), scheint es einen API-Befehl zu ermitteln der Taktrate zu geben. Da müsste man mal nachharken.
Wer misst misst Mist.
Hehe
Verfasst: 13.03.2005 01:05
von MVXA
Bei mir ist dieser Code eigentlich sehr genau. Ich habe ein AMD athlon xp 2000+ (1,6666 GHz) und erkennen tut es 1,6558
Verfasst: 13.03.2005 01:25
von Laurin
Du hast kein Cool'n'Quiet in deinem Chip. Wenn mein Prozessor kaum genutzt wird, taktet er sich auf 1 Ghz runter (Mutliplikator 5). Fährt er unter Vollast, taktet er mit 2,2 Ghz (Mutliplikator 11).
Das ist das Problem.
Wie gesagt, es gibt einige Programme, die trotz allem den maximalen Ghz-takt erkennen (DxDiag.exe).
Verfasst: 13.03.2005 01:44
von Froggerprogger
Vielleicht muss man einfach andersherum sich darüber freuen, dass der Code das so macht, denn er zeigt definitiv die Differenz des Prozessortaktzählers von 2 Zeitpunkten, die nahezu haargenau im angegebenen Abstand voneinander liegen, an. Wenn dann dxdiag sagt 5GHz, kannst Du mit diesem Code das Gegenteil herausfinden
Eine Alternative kenne ich nicht (heißt aber nix), aber zumindest steht in der CPUID keine Geschwindigkeit (außer die grobe Einteilung Pentium 1,2,3,4) drin, nur genauer Prozessortyp, etc.
Verfasst: 13.03.2005 01:59
von Laurin
Nee, die CPUID hilft da nicht. Ich glaube da stehen nur Name, Model, Stepping etc. und die Erweiterungen wie SEE drin.
Woher bekommt DxDiag seine Infos?
Greetz Laurin
Verfasst: 14.03.2005 15:26
von Helle
Bei mir zeigt dxdiag die z.Z. tatsächliche Taktfrequenz (also auch wenn
QnQ aktiv ist) an; dann z.B. 1GHz. Dass dxdiag diesen Wert erst ermittelt
erkennt man auch daran, dass er mit zeitlicher Verzögerung angezeigt wird. Übertakte ich die Kiste, werden auch höhere Werte angezeigt. Alle
Werte decken sich sehr gut mit den Werten von Froggerproggers Pro-
gramm.
Eventuelle Abhilfe für zu ungenaue Angaben: In der Literatur wird für den
Einsatz von RDTSC empfohlen, ihn mit einem serialisierenden Befehl wie
z.B. CPUID zu "umhüllen". Beim Auslesen des TSC wird nicht auf gerade laufende Prozesse geachtet. CPUID davor stellt sicher, dass beim Aufruf
von RDTSC Ruhe in der Kiste ist. Wohlgemerkt, die Rückgabe-Werte von
CPUID interessieren hier überhaupt nicht!
Gruss
Helle
Verfasst: 15.03.2005 20:50
von DarkCrow
Also folgende Prozedur funktioniert auch bei meinem Freund ...
Code: Alles auswählen
Procedure.l CalcCPUSpeed()
DelayTime = 500
TimerHi = 0
TimerLo = 0
PriorityClass = GetPriorityClass_(GetCurrentProcess_())
Priority = GetThreadPriority_(GetCurrentThread_())
SetPriorityClass_(GetCurrentProcess_(),100)
SetThreadPriority_(GetCurrentThread_(),15)
Sleep_(10)
!CPUID
!DW 310Fh ; rdtsc
MOV TimerLo, EAX
MOV TimerHi, EDX
Sleep_(DelayTime)
!CPUID
!DW 310Fh
SUB EAX, TimerLo
SUB EDX, TimerHi
MOV TimerLo, EAX
MOV TimerHi, EDX
SetPriorityClass_(GetCurrentProcess_(),Priority)
SetThreadPriority_(GetCurrentThread_(),PriorityClass)
ProcedureReturn (TimerLo / (1000.0 * DelayTime))
EndProcedure
Verfasst: 15.03.2005 21:44
von Laurin
@DarkCrow:
Ich bekomme bei deinem Code immer einen Fehler bei
Fehler: 'TimeLo' is not a valid Operator.
Weiß jemand den Grund?