Delphi-PRAXiS
Seite 6 von 16   « Erste     456 78     Letzte »    

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Software-Projekte der Mitglieder (https://www.delphipraxis.net/26-software-projekte-der-mitglieder/)
-   -   CPUiD 3.0 - Ein kleines System - Diagnoseprogramm (https://www.delphipraxis.net/49749-cpuid-3-0-ein-kleines-system-diagnoseprogramm.html)

Luckie 3. Jan 2006 14:27

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.

himitsu 3. Jan 2006 14:37

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

Daniel G 3. Jan 2006 19:57

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
Zitat:

Zitat von Luckie
Nein, ich meine CPUID, so heißt doch das Programm von Daniel oder?

Ah, nicht ganz:

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

negaH 4. Jan 2006 12:20

Re: CPUiD 2.0.1 - Ein kleines CPU - Diagnoseprogramm
 
Zitat:

Vor der Messung sollte die Priorität des Prozess auf TIME_CRITICAL gesetzt werden und danach natürlich wieder zurück. Ich habe festgesttelt, dass dies bei CPUID wohl nicht passiert, zumindest zeigt der Taskmanager nichts an in dieser Richtung.

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:
  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;
PerformanceFrequency ist meistens 1.6Mhz, also auf 1/1600000 Sekunde exakt. Sleep ist 1/1000 Sekunde exakt und der Tasksheduller funkt auch noch dazwischen.

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

Daniel G 14. Jan 2006 22:29

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:
CPUiD PreAlpha 3.0 (~350 kb)
Screenshot (~60 kb)

MagicAndre1981 14. Jan 2006 22:36

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:

Daniel G 14. Jan 2006 22:37

Re: CPUiD 3.0 - Ein kleines CPU - Diagnoseprogramm
 
Zitat:

Zitat von MagicAndre1981
:shock: 4V Core-Spannung bei einem Athlon XP T-Bred-B :shock:

Ich glaub da stimmt was nicht :wink:

Let's burn that shit! :D

Aber komisch... Immerhin wirds bei mir korrekt angezeigt... Ich hole mir die Informationen nur via SMBIOS...

EDIT:
Welche SMBIOS - Version haddu denn?

Basilikum 14. Jan 2006 23:00

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

Daniel G 14. Jan 2006 23:13

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?

Basilikum 14. Jan 2006 23:23

Re: CPUiD 3.0 - Ein kleines CPU - Diagnoseprogramm
 
Zitat:

Zitat von Daniel G
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?

diese beiden Felder sind meiner Zensur zum Opfer gefallen... sie wurden einwandfrei ermittelt..... angemeldet bin ich mit lokalen Administratoren-Privilegien...


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:04 Uhr.
Seite 6 von 16   « Erste     456 78     Letzte »    

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