![]() |
Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
Nein, ich meine CPUID, so heißt doch das Programm von Daniel oder? Und das scheint eben nicht die Prozesspriorität entsprechend zu setzen, das sollte man aber machen, um einen möglichst genauen Wert zu bekommen.
|
Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
ach stimmt ja, X'D
aber daß machen eh kaum jemand und selbst Hagen (also auch ich) stellt das nicht extra um und es funktioniert dennoch ^^ |
Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
Zitat:
CPUiD Man achte auf das kleine "i" in Anlehnung an mein Lieblings - Delphi - Forum. :zwinker: Zum Geschwindigkeitsproblem: Ich werde noch einige weitere Tests mit anderen Methoden machen. Woll'n wir mal sehen... |
Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
Zitat:
Nein das ist nicht wirklich nötig. Es hängt nur von der verwendeten Methode der Zeitmessung ab. Es gibt die absolute Messung und die relative Messung. Misst man zb. per einfachem Sleep(1000) so ist dies eine absolute Messung und bei dieser sollte man mit hoher Priorität messen. Nimmt man aber eine relative Messung, zb. RDTSC + PerformanceCounter dann x Millisekunden warten und dann wieder RDTSC + PeformanceCounter dann hat man qausi zwei unabhänig laufende Zeitbasen in Form von der Differenz in RDTSC und PerformanceCounter. Die Wartezeit zwischen den Messungen wird dann quasi irrelevant da beide Counter unabhängig vom Tasksheduller arbeiten. Davon abgesehen ist der Performancecounter weit genauer in der Auflösung als Sleep(). Ich hatte hier im Forum aber schon mal meine Messmethode erklärt und auch auf exakt diese Vorteile gegenüber Sleep() oder GetTickCount() hingewiesen. Es sieht also so aus: - man benötigt eine möglichst genaue und unabhängig laufende Zeitbasis, zb. der Peformancecounter läuft mit 1.6 MHz - man führt nun eine Relativmessung durch
Code:
PerformanceFrequency ist meistens 1.6Mhz, also auf 1/1600000 Sekunde exakt. Sleep ist 1/1000 Sekunde exakt und der Tasksheduller funkt auch noch dazwischen.
Basis := PerformanceCounter;
Messung := RDTSC; warte par Millisekunden, könnte auch Sleep() sein, ist aber irrelavent Basis := PerformanceCounter - Basis; Messung := RDTSC - Messung; Frequenz := Basis / PerformanceFrequency * Messung; Misst man mit der Relativmessung eine 3.2GHz CPU aus so wird man also auf +-2000 Taktzyklen exakt diese berechnen können. Mit Spleep()/GetTickCount im besten Falle auf +-3200000 Taktzyklen. Der Unterschied un der Genauigkeit beträgt also das 1600'fache. Benutzt man Sleep() und TIME_CRITICAL Priorität so ist das kein Garant dafür das zb. Sleep(100) auch wirklich 100 Millisekunden dauert. Denn die Betriebsystemsoftware benötigt für das Sleep() selber immer auch einigen Overhead an zeit. Angenommen das wären bei Sleep(100) nur 1 Millisekunde mehr, also Sleep(100) dauert 101 Millisekunden so hat man bei 1 Sekunde Messdauer schon 10% Fehler drinnen. Eine 3.2GHz CPU würde also als 2.9GHz CPU gemessen. Testet man Sleep(100) mit dem PerformanceCounter so wird man feststellen das auf den meisten CPUs das Betriebsystem eine feste Konstante als Overhead davon abzieht. D.h. Sleep(100) wird in den meisten fällen weniger als 100ms dauern. Ergo: eine darauf basierende CPU Frequenzberechnung wird die CPU Frequenz leicht überhöht ausrechnen. RDTSC und der Peformancecounter sind in Hardware völlig unabhängig laufende Zähler/Timer. RDTSC hat die Frequenz zum aktuellen internen Takt der CPU. PerformaceCounter basiert auf der Realtimeclock im RTC BIOS Chip und läuft mit ca. 1.6MHz. In einigen Rechnern wird der PerformanceConterdurch das OS aus dem RDTSC generiert. Dies wird dann auf Nootbook CPUs bzw. CPU's mit variable Taktanpassung zu Problemen führen. Gruß Hagen |
Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
(Danke, Hagen :zwinker: )
Pre-Alpha Version 3.0 Um euch vorzuwarnen: Bei dieser Version handelt es sich um eine absolut frühe Version, die noch nicht aus dem BETA - Stadium heraus ist. Einige Dinge müssen noch gefixt und implementiert werden. Dazu gehören: - Exceptionhandling - Funktionstest unter Windows 9x - "CPU - Cache" - Tab benötigt noch etwas Bearbeitungszeit - Hilfe-Datei - Report-Funktion - Einstellungs-Dialog Weiterhin gilt übrigens: Das Programm benötigt keinen Treiber und keine Administratorrechte Mal eine kleine Liste von Dingen, die neu sind: Allgemein: - GUI einer kleinen Schönheitskur unterzogen Prozessorinformationen: - Anzeige des FSB und des Multiplikators* - Anzeige des Hersteller - Logos Allgemeine Informationen(OS, Benutzername, Computername, System - UpTime)* (NEU) Speicherinformationen(Bandbreite, Größe, Takt)* (NEU) *Was genau an Informationen angezeigt wird, hängt von der SMBIOS - Version ab. Is' aber trotzdem 'ne dolle Sache :D Download: ![]() ![]() |
Re: CPUiD 3.0 - Ein kleines CPU - Diagnoseprogramm
:shock: 4V Core-Spannung bei einem Athlon XP T-Bred-B :shock:
Ich glaub da stimmt was nicht :wink: |
Re: CPUiD 3.0 - Ein kleines CPU - Diagnoseprogramm
Zitat:
Aber komisch... Immerhin wirds bei mir korrekt angezeigt... Ich hole mir die Informationen nur via SMBIOS... EDIT: Welche SMBIOS - Version haddu denn? |
Re: CPUiD 3.0 - Ein kleines CPU - Diagnoseprogramm
Liste der Anhänge anzeigen (Anzahl: 1)
irgendwo stimmt etwas nicht bei der Frequenz-Messung... die Messung dauert ziemlich exakt 30s, wobei der eine "CPU" zu 100% ausgelastet ist... (Pentium IV 2.8 GHz, Hyperthreading enabled)... FSB stimmt mit Angabe von CPU-Z überein...
|
Re: CPUiD 3.0 - Ein kleines CPU - Diagnoseprogramm
In der Tat komisch, zumal, wie ich gerade sehe, weder der Benutzername noch der Computername ermittelt wird...
Bist du als Admin oder mit eingeschränkten Nutzerrechten angemeldet? |
Re: CPUiD 3.0 - Ein kleines CPU - Diagnoseprogramm
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 14:04 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz