Open Hardware Monitor (Version 0.2.1 Beta)

[mmoeller]

könnte man im Prinzip schon, aber die 3. Stelle nach dem Komma stimmt eh nicht mehr.

Die Auflösung des Winbond W83667HG Messeingangs für VCore ist 0.008V. Wenn die Spannung also 1.224V ist, dann ist die nächsthöhere 1.232V. Dann geht es mit 1.240V, 1.248V, 1.256V, 1.264V, 1.272V weiter.

Gerundet wäre das: 1.22V, 1.23V, 1.24V, 1.25V, 1.26V, 1.26V, 1.27V. Ganz selten geht ein bisschen Information verloren (1.256V und 1.264V werden beide als 1.25V dargestellt). Aber ich gehe davon aus, dass das letzt Bit eh nicht super genau ist, wodurch sich das dann erübrigt.

Wenn wir 1.256V anzeigen täuscht das halt auch vor, dass die Spannung 1.256V ist und nicht 1.252V oder 1.259V, obwohl beides dar Fall sein könnte.

---------- Beitrag hinzugefügt um 19:26 ---------- Vorheriger Beitrag war um 15:38 ----------

Ich habe soeben die Version 0.2.0 Beta hochgeladen, welche die ganzen Verbesserungen der Alpha Versionen in einem Beta Release sammelt.

 

[norT]

Version: 0.2.0.0

System.IO.FileNotFoundException: Could not load file or assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Das System kann die angegebene Datei nicht finden.
File name: 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Das System kann die angegebene Datei nicht finden.
File name: 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

   at OpenHardwareMonitor.GUI.ReportForm.sendButton_Click(Object sender, EventArgs e)
   at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
   at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.ButtonBase.WndProc(Message& m)
   at System.Windows.Forms.Button.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)



System.IO.FileNotFoundException: Could not load file or assembly 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Das System kann die angegebene Datei nicht finden.
File name: 'System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].


Common Language Runtime: 4.0.30319.1
Operating System: Microsoft Windows NT 6.1.7600.0
Process Type: 64-Bit

hab nur einen bericht hochladen wollen und konnte dan auch den crash report nicht senden.

edit:
der fehler kommt immer wieder wen ich auf submit report geh und dan send klicke

 

[mmoeller]

Danke, das muss ich mir genauer anschauen. Ein "Quick-Fix" dürfte folgendes sein: Die Datei OpenHardwareMonitor.exe.config aus dem OHM Verzeichnis löschen.

 

[norT]

ja funktioniert, sobald ich die OpenHardwareMonitor.exe.config wieder ins verzeichniss kopiere und OHM neustarte stürzt er wieder ab an der stelle

edit:

das verändern des FSB im windows bestrieb zeigt der OHM nicht an dafür muss ich ihn neustarten z.b. CPU-Z zeigt die veränderungen sofort an

edit2:
selbst das neustarten von OHM zeigt nicht die aktuelle FSB und MHz an

 

[mmoeller]

Kannst du mal zwei Reports posten, einen vor dem ändern des FSB und einen nach dem ändern des FSB (jeweils mit OHM neu starten).

 

[norT]

habe OHM ausgemacht FSB auf Orginal gestellt dan OHM neugestartet und einen bericht gemacht, dan OHM wieder geschlossen und den FSB auf 405 und anschliessend OHM gestartet und einen bericht gemacht.

 

[mmoeller]

Danke. Was beim Ändern des FSB im laufenden Windows genau passiert verstehe ich nicht. Entweder läuft der TSC (Time Stamp Counter) auch beim veränderten FSB mit der alten Frequenz weiter. Das geht aber rein von der Hardware her schon nicht, würde ich meinen. Oder die Timing Funktionen von Windows werden verfälscht, da diese nicht mit einem spontanten Ändern des FSB rechnen. Wenn das "Zeitgefühl" von Windows genau im gleichen Mass verfälscht wird wie der FSB, dann sieht es so aus als würde der FSB noch mit der alten Frequenz laufen.

Für das Crash Problem habe ich einen neue Alpha Version, die das beheben sollte (auch ohne löschen der .config Datei):

http://openhardwaremonitor.org/openhardwaremonitor-v0.2.0.1-alpha.zip

Bitte Testen und Berichten

 

[Grummel]

[/COLOR]Ich glaube Ich habe noch einen kleinen Fehler gefunden, was den zu tiefen Wert verursachen könnte.

@KAxel: Kannst du bitte mit dieser Version

http://openhardwaremonitor.org/openhardwaremonitor-v0.1.37.24-alpha.zip

nochmals testen?

Bei mir hats funktioniert. Ich hatte den gleichen Fehler mit der FSB Zahl. Nu passt es.

Aber ich habe eine andere "Merkwürdigkeit" entdeckt (in der v24):



Direkt nach dem Start sitzen die Min-Max Werte für die CPU Auslastung fest aus 0% bzw. 100% - ich meine, das war vorher nicht der Fall (auch wenn ich es jetzt nicht beschwören würde...).

Ist aber nicht weiter wild. So wie der OHM ist, ist er schon genial.

 

[norT]

also das report senden funktioniert aber vielleicht solte ein status balken oder ein fenster nach abschluss kommen das bestätig das der report gesendet wurde weil bei mir hängt sich das programm auf und dan verschwindet das fenster report senden

FSB ist wie voher bei veränderung

 

[mmoeller]

Hier mal ein Versuch das FSB Problem zu beheben. Ein Neustart des OHM ist in jedem Fall noch notwendig auf Core 2 CPUs.

http://openhardwaremonitor.org/openhardwaremonitor-v0.2.0.2-alpha.zip

Die Version 0.2.0.2 Alpha verwendet jetzt einen anderen Timer um die Zeit zu messen. Vielleicht ist es ja damit besser.

@Grummel: ja das ist relativ schwierig zu verhindern, da der OHM ja bei starten auch selber Last erzeugt. Aber man kann es ja auch noch zurücksetzten (View / Reset Min/Max).

 

[norT]

jau funktioniert danke, der neustart ist aber nicht ganz so schön

 

[mmoeller]

Auf den Core 2 CPUs wird es etwas schwierig die FSB Taktrate online zu messen.

Wäre noch interessant ob die Version 0.2.0.2 Alpha

http://openhardwaremonitor.org/openhardwaremonitor-v0.2.0.2-alpha.zip

auch of Core i5/i7 bzw AMD Systemen sauber funktioniert. Denn wenn man Dinge wie den Timer ändert kann es gut sein, dass es plötzlich woanders Probleme gibt.

 

[KAxel]

Bei mir zeigts jetzt dauernd wechselnde Werte um den Bus Clock 199/200/201 daraus schwankt dann die MHz Core Clock mit....

Der Min Wert ist jetzt auch wieder komisch

Wenn ich mal nen Wunsch äussern darf: Ist es möglich den Watt Verbrauch der CPU oder gar der GPU anzuzeigen ?

 

[Seadersn]

mmoeller, du bist der hammer so viel (guten, hochwertigen) support von einer one man group hab ich bei noch keinem project kennengelernt dank dir

 

[mmoeller]

@KAxel: Danke für das Feedback. Der Timer den ich in die Version 0.2.0.2 Alpha eingebaut habe scheint im allgemeinen zwar etwas robuster gegen Änderungen des FSB, aber zu ungenau. Immerhin bin ich anhand der Tests sicher, dass das Problem bei der Funktion QueryPerformanceCounter bzw. QueryPerformanceFrequency liegt. Laut Dokumentation kann sich die Frequenz des Timers nicht ändern "The frequency cannot change while the system is running.". Falls der QueryPerformanceCounter aber den Time Stamp Counter (TSC) als Basis verwendet und man den FSB ändert, dann müsste er sich anpassen. Aud Systemen auf denen der QueryPerformanceCounter einen anderen Hardware Timer verwendet dürfte das Problem nicht auftauchen. Ich behalte daher erstmal die alte Implementierung (wie in der Version 0.2.1 Beta), da der Fehler beim ändern des FSB genau genommen ein Fehler im Betriebsystem ist. Es scheint da Workarounds zu geben (siehe CPU-Z), aber das hat im Moment nicht so extrem hohe Priorität.

@Seadersn: Seit etwa zwei Wochen unterstützt mich auch noch Paul Werelds beim coden, die CPU Clock Implementierung für AMD K8 ist z.B. von ihm.

 

[kief]

Hi,

zuerstmal vielen Dank für das Super Programm.

Nun zu meiner Frage:
Ist es normal das OHM >10MB an Hauptspeicher benötigt ? Bei mir wird im Mittel 11MB Hauptspeicher belegt. HWMonitor kommt hingegen mit ca. 4MB aus. Nicht das mich das jetzt stört (hab ja genügend RAM ) aber ich frage mich hald warum OHM bedeutend mehr RAM benötigt als HWMonitor.

der_Kief

 

[Nuke8472]

Bei mir liegt OHM mit 3,4 MB im Speicher. Also weit von deinen 11 MB entfernt

 

[kief]

Bei mir liegt OHM mit 3,4 MB im Speicher. Also weit von deinen 11 MB entfernt

Versteh ich jetzt nicht warum bei Dir nur so "wenig" RAM belegt wird. Vielleicht hängt das ja von der Menge an ausgelesenen Sensoren ab ?

der_Kief

 

[Arikus83]

bei mir sinds sogar 15MB.

evtl kann uns ja mmoeller sagen, wieso das so unterschiedlich ist.

 

[anticucho]

ihr seit ja schlecht

 

[Nuke8472]

Hat wahrscheinlich wirklich was mit der Menge an ausgelesenen Sensoren zu tun.

 

[mmoeller]

Das mit der Speichernutzung ist ziemlich kompliziert, da es bei Windows inzwischen die verschiedensten Arten von Speichernutzung gibt. Und Windows entsprechend auch verschiedene Arten von "RAM" dafür verwendet, je nach dem z.B. die Festplatte.

Was im Task Manager angezeigt wird, ist normalerweise das "Private Working Set" (wenn ich mich recht erinnere). Das ist also der Teil des RAMs welcher sich der Prozess nicht mit anderen Anwendungen / Betriebssystemteilen teilt (private). Zudem ist das auch nur der Teil des RAMs auf welchen "aktiv zugegriffen" wird (working set), bzw. mit welchem das Programm arbeitet. Die Grösse von diesem Teil kann in gewissen Grenzen vom Programm bzw. dem .NET Framework beeinflusst werden. Wenn der freie Speicher im System für andere Programme knapp wird, dann wird das "Private Working Set" so weit reduziert wie möglich (was dann aber auch etwas mehr CPU Last zur folge hat). Wenn genug Speicher vorhanden ist, dann bleibt es etwas grösser (wodurch sich die CPU Last durch Memory Management etwas reduziert). Was man also im Task Manager als Memory sieht, hängt also auch sehr stark vom System und den anderen Prozessen ab.

Der gesamte private Speicher den der Open Hardware Monitor anfordert ist normalerweise etwa 40MB gross, wobei der aktive davon genutzte Teil eben wesentlich kleiner ist. Besonders viel dagegen tun kann man nicht, da schon eine "leere" .NET GUI Anwendung sich normalerweise ca. 25MB genehmigt. Zudem soll das beim Memory Management von Windows nicht wirklich eine Rolle spielen.

Der Hauptunterschied in der sichtbaren RAM Nutzung zwischen dem CPUID HWMonitor und dem Open Hardware Monitor kommt wohl davon, dass der CPUID HWMonitor als native Win32 Anwendung läuft, und der Open Hardware Monitor als managed .NET Anwendung.

Falls der Speicher wirklich knapp wird, sollte die vom Open Hardware Monitor erzeugte Speicherlast nicht viel grösser sein als beim CPUID HWMonitor.

 

[anticucho]

ach diese speicherdiskussion geht mir aufn zeiger und is useless. der programmstart geht ratzfatz und wozu hab ich 6gb onboard?

 

[kief]

Das mit der Speichernutzung ist ziemlich kompliziert, da es bei Windows inzwischen die verschiedensten Arten von Speichernutzung gibt. Und Windows entsprechend auch verschiedene Arten von "RAM" dafür verwendet, je nach dem z.B. die Festplatte.

Was im Task Manager angezeigt wird, ist normalerweise das "Private Working Set" (wenn ich mich recht erinnere). Das ist also der Teil des RAMs welcher sich der Prozess nicht mit anderen Anwendungen / Betriebssystemteilen teilt (private). Zudem ist das auch nur der Teil des RAMs auf welchen "aktiv zugegriffen" wird (working set), bzw. mit welchem das Programm arbeitet. Die Grösse von diesem Teil kann in gewissen Grenzen vom Programm bzw. dem .NET Framework beeinflusst werden. Wenn der freie Speicher im System für andere Programme knapp wird, dann wird das "Private Working Set" so weit reduziert wie möglich (was dann aber auch etwas mehr CPU Last zur folge hat). Wenn genug Speicher vorhanden ist, dann bleibt es etwas grösser (wodurch sich die CPU Last durch Memory Management etwas reduziert). Was man also im Task Manager als Memory sieht, hängt also auch sehr stark vom System und den anderen Prozessen ab.

Der gesamte private Speicher den der Open Hardware Monitor anfordert ist normalerweise etwa 40MB gross, wobei der aktive davon genutzte Teil eben wesentlich kleiner ist. Besonders viel dagegen tun kann man nicht, da schon eine "leere" .NET GUI Anwendung sich normalerweise ca. 25MB genehmigt. Zudem soll das beim Memory Management von Windows nicht wirklich eine Rolle spielen.

Der Hauptunterschied in der sichtbaren RAM Nutzung zwischen dem CPUID HWMonitor und dem Open Hardware Monitor kommt wohl davon, dass der CPUID HWMonitor als native Win32 Anwendung läuft, und der Open Hardware Monitor als managed .NET Anwendung.

Falls der Speicher wirklich knapp wird, sollte die vom Open Hardware Monitor erzeugte Speicherlast nicht viel grösser sein als beim CPUID HWMonitor.

Vielen Dank für die umfangreiche Aufklärung

ach diese speicherdiskussion geht mir aufn zeiger und is useless. der programmstart geht ratzfatz und wozu hab ich 6gb onboard?

brauchst Dich ja nicht dran beteiligen ...

der_Kief

 

[Peyota]

ich seh in 40mb nun wirklich kein Problem vor allem wenn ich sehe was Firefox so frist

 

[kief]

Hi,

das auslesen der Lüfterdrehzahlen funktioniert bei meinem Board leider nicht richtig. Mal werden Drehzahlen angezeigt an denen gar kein Lüfter angeschlossen ist, mal werden nur ein Lüfter angezeigt und mal werden utopisch hohe oder niedrige Werte angezeigt. Das Problem haben andere Tools wie z.B. HWMonitor oder Speedfan auch. Das Board hat einen IT8720F Chip drauf. Alle anderen Werte die den IT8720F betreffen werden korrekt ausgelesen. Da einzige Tool das die Drehzahlen korrekt ausliest ist das Boardhersteller Eigene Tool "OC Tuner".

der_Kief

 

[mmoeller]

Tritt das Problem auch auf wenn du alle anderen Hardware Monitoring Tools (inklusive CPU-Z) beendet hast? Kannst du mal einen Report posten?

 

[kief]

Tritt das Problem auch auf wenn du alle anderen Hardware Monitoring Tools (inklusive CPU-Z) beendet hast? Kannst du mal einen Report posten?

Ja das Problem tritt auch auf wenn alle anderen Tools geschlossen sind. Hab Dir geraden einen Report zugesendet.

der_Kief

 

[aj69]

Nochmal vielen Dank für das super Tool!
Jetzt wäre ein bischen Optik im Gadget noch schön

Gruß
aj

 

[mmoeller]

@kief: Danke für den Report. Ich hab mir das mal angesehen, aber ich verstehe nicht genau was da schief läuft. Bei den ITE Super I/Os kann man bei den Fans eigentlich nicht so viel falsch machen.

@aj69: was für Optik fehlt denn noch?