Auslesen von WMI dauert (zu?) lange

[himitsu]

Zitat:

wbemFlagReturnImmediately and wbemFlagForwardOnly

Mathematik:

Delphi-Quellcode:

$0001 and $0008 = 0 // nichts 
$0001 or $0008 = $0009 // Beides

Der Takt hat aber keine Aussagekraft darüber, ob verwendbare Rechenzeiten übrig sind.
Die Zeiten können das aber sagen, unabhängig vom CPU-Takt.

Ein niedriger Takt sagt nur aus, dass schon längere Zeit kaum etwas gerechnet wird,
aber es kann auch aussagen, dass die CPU viel zu sehr ausgelastet ist und wegen Übertemperatur in den Schutzmodus versetzt wurde,
oder ...

Bei diesem PC hier ist es sogar so, dass der aktuell nicht auf "Leistung" optimiert ist, sondern auf Energieverbrauch und Lautstärke. (nur wenn längere Zeit voll ausgelastet, wird hochgetaktet).
Also meistens kann man dem Takt garnicht ansehen, ob und wie hoch die Auslastung ist.

Bei den CPU-Zeiten ist es dagegen recht einfach.
* 4 Kerne haben 400% Rechenzeit
* Wenn also in einer Minute alle Zeiten zusammengerechnet nur 2 Minuten ergeben, ist die CPU somit zu mindestens 50% arbeitslos gewesen. (noch mehr arbeitslos, wenn der Takt noch höher werden kann, aber das ist egal)
* CPUZeiten / Messinterval / AnzahlDerKerne * 100 = Auslastung in Prozenz
* (CPUZeitenJetzt - CPUZeitenLetztesInterval) / (ZeitJetzt - ZeitLetzteMessung) / AnzahlDerKerne * 100 = Auslastung in Prozenz

Diese Berechnung hilft aber nur, wenn man multithreaded arbeitet.
Bei Single-Thread könnte man statt der Zeiten aller Kerne nur den Kern mit der meisten Rechenzeit nehmen, bzw. die freien Zeiten des Kerns, auf dem man grade läuft, bzw. besser die Zeiten seines eigenen Threads/Prozesses.

[Shark99]

Hab heute mehrere Stunden zu dem Thema gegoogelt, weil ich bei dem Projekt von WMI wegkommen wollte. Derzeit bleibe ich bei WMI, weil viele Werte wie z.B. DPCRate aus Win32_PerfFormattedData_Counters_ProcessorInformat ion nicht ohne WMI oder Kerneltreiber zu emitteln sind.

Bei der CPU Frequenz ist alles sehr problematisch. Irgendwelche Takte zu zählen ist genauso ungenau wie die WMI Werte. Meine Kiste ist von 4 auf 4.6 Ghz übertaktet. Die CPU Frequenz wird von CPU-Z und HWInfo64 korrekt als 4,6 GHz unter Last angezeigt, WMI und die Taktzählerei über Performance Counters ergibt 4.0 GHz. Richtige Werte bekommt man nur über einen Kernel Treiber, was CPUZ und HWInfo 64 ja machen.

Wenn eine x86 CPU überhitzt und drosselt geht sie nicht auf Minimaltakt runter (d.h. unter den Nominaltakt, Turbo bleibt natürlich aus), was bei vielen ARM Prozessoren der Fall ist, sondern lässt Takte aus. Es gibt ein hin und her zwischen C-States und Nominaltakt. CPUZ etc zeigen dann aber konstant den Nominaltakt an.

Wenn weniger als 1GHz anliegt hat die CPU entweder nichs zu tun, oder Stromsparprofil ist aktiv. Wenn weniger als 1GHz anliegt und das Delta von TSystem_Performance_Information64.IdleTime in Vergleich zu Systemtime unter 10% liegt kann man sicher davon ausgehen dass die CPU idle ist. Die alleinige Betrachtung der Idletime reicht auf keinem Fall aus, weil sich die Prozentwerte zu Systemtime zwischen 800Mhz und 4GHz nicht ändern. Ein Idle-Wert von 20% bei 800MHz hat ja eine ganz andere Bedeutung wie ein Idle-Wert von 20% bei 4GHz.

[Shark99]

Zitat von himitsu:

Zitat:

wbemFlagReturnImmediately and wbemFlagForwardOnly

Mathematik:

Delphi-Quellcode:

$0001 and $0008 = 0 // nichts 
$0001 or $0008 = $0009 // Beides

Ich nehme an der Code wurde von Google übernommen z.B von hier

https://stackoverrun.com/de/q/597183

Wahrscheinlich falsch übersetzt aus MS VB Beispielen. Aus wbemFlagReturnImmediately + wbemFlagForwardOnly in VB wurde ein AND in Delphi. p.s. Ändert aber nichts an der Trägheit des Query. Kein Unterschied zwischen $0 und $9.

[himitsu]

Nja, ein + gibt es auch im Delphi, aber 4 + 4 = 4, was man nur mit dem OR richtig hinbekommt.

Delphi-Quellcode:

loc := TSWbemLocator.Create(nil);
Services := Loc.ConnectServer(...);

Den Teil könnte man auslagern und anstatt es jedes Mal neu zu machen nur einmal am Anfang, aber der Teil braucht hier auch kaum Zeit.