CPU-Stressoren für den Pentium 4

[chrom]

In Ergänzung zu Rio's Klassiker "wie teste ich, ob mein system richtig stabil ist" untersuchte ich auf meinem P4-System Ende letzten Jahres einmal, was einzelne CPU-Stressoren tatsächlich zu leisten imstande sind. Nachdem ich das Projekt zeitweilig aus den Augen verloren hatte, will ich Euch die wichtigsten Ergebnisse nun nicht länger vorenthalten.

Zunächst stelle ich Vergleichsergebnisse (Teil 1) vor, bevor ich einige prototypische Stressoren im Detail darstelle (Teil 2). Angaben zu Testsystem und -ablauf folgen im Text, zusammenfassend und ausführlicher dann ganz am Ende (Teil 3).

1.1 Temperatur-Vergleich:

Das Diagramm zeigt den Mittelwert der CPU-Temperatur nach 30min Belastung durch den jeweiligen Stressor zusammen mit dem Modalwert. Der Modalwert ist übrigens der häufigste gemessene Wert.

Die Abkürzungen der Y-Achse stehen für alle getesteten Programme:
- BurnMax = BurnMax
- BurnK7 = auf den Athlon optimiertes Modul von CPUburn
- BurnP6 = CPUburn-Modul für Intel PentiumPro, PentiumII&III und Celeron
- P95 In-pl lFFT = Primzahlen-Cruncher Prime95 (Ver. 23.7.1), "Torture Test" im Modus "In-Place large FFTs"
- CPUburnIn = CPUburnIn 1.01
- P95 Blend = Prime95 Torture Test im Modus "Blend"
- P95 sFFT = Prime95 Torture Test im Modus "Small FFTs"
- StressCPU = StressCPU
- 3Dmark2001SE = Ihr dürft mal raten
- WinTR n! = Berechnung der Fakultät von 1.000.000.000.000.000! mit dem Windows-Taschenrechner
- Realstorm = Raytracer Realstorm Bench 2004
- PiFast = Pi-Cruncher PiFast 43
- BurnMMX = Ein weiteres Modul aus CPUburn, optimiert auf alle CPUs mit MMX
- Sandra2003 = Sisoftware Sandra Standard 2003
- Totaltest = Fraktale-Generator Totaltest 1.0
- SETI = Rio's SETI-Bench
- SuperPI = veralteter Pi-Cruncher Super PI Ver1.1e
- MBM Heatup = einfacher Heizer aus dem Motherboard Monitor-Package
- Tw4U_Toaster = Tweakers4U-Toaster 2.0

Sieht man sich die durchschnittlichen Temperaturen und v.a. auch den Modalwert an, wird rasch deutlich, welches Stress-Programm dem P4 am stärksten einheizte: BurnMax führt den Vergleich deutlich an. Dieses unbekannte, unkommentierte Tool eines unbekannten dänischen Meisters kann - obwohl im Vergleich zu Veteranen wie SuperPi oder BurnMMX geradezu taufrisch - inzwischen leider nicht einmal mehr irgendwo offiziell heruntergeladen werden. Da der Autor die Weiterverbreitung nicht weiter reglementierte, stelle ich es selbst zum Download bereit (s. Link in der Liste).

Von der Kerntemperatur darf man annehmen, dass sie indirekt die Belastung einer CPU spiegelt. Interessant sind obige Ergebnisse aber vor allem für jene, die die Leistungsfähigkeit ihrer Prozessorkühlung auch für extreme Situationen sicherstellen wollen. Weder das übliche Prime95, noch das früher hier so beliebte BurnMMX, und schon gar nicht SETI vermögen dabei die Grenzen so gnadenlos auszuloten, wie der Nobody BurnMax es schafft.


1.2 Vergleich der CPU-Last:

Das nächste Diagramm benötigt eine Einführung:
Gleichzeitig mit der Messung von Temperatur, Vcore und anderen hardwareseitigen Kennwerten wurde im 1-Sekunden-Rhythmus die tatsächliche Prozessorauslastung protokolliert. Wie intensiv eine CPU durch bestimmte Prozesse ausgelastet ist, teilt bekanntlich schon der Windows Task-Manager (Win2k/WinXP) mit. Auch MBM offeriert einen entsprechenden Sensor, der offenbar schlicht die Windows-Werte durchstellt. Leider wertet Windows jedoch auch die vielen unproduktiven Wartezyklen als Last, die moderne Prozessoren während der Abarbeitung eines Threads einzulegen gezwungen sind (vgl. M. Withopf, Virtuelles Tandem, c't 24/2002). So kommt es, dass der Task-Manager mit seiner Anzeige der CPU-Nutzung doch erheblich übertreibt.
Das c't-Tool PerfWatch beschreitet da einen direkteren Weg: Es liest spezielle CPU-Register aus, die Intel mit der Netburst-Architektur (P4, Xeon) realisierte, die so genannten Performance-Counter. Für seine Anzeige der CPU-Last wertet es die Anzahl abgeschlossener Mikro-Operationen ("µops-retired") je Taktzyklus aus.
Die mir vom Autor Matthias Withopf auf meine Anfrage dankenswerter Weise übersandte fortentwickelte Version 1.3 erlaubt per Befehlszeilenparameter nun auch das Mitschneiden der Ergebnisse. Wie stark sich die Angaben zur CPU-Last zwischen PerfWatch vs. Windows Task-Manager unterscheiden, zeigt ein Beispiel: Auf nachfolgender Abbildung lastet das Testprogramm für den Arbeitsspeicher MemTest die CPU laut PerfWatch zu maximal 9% aus, während der Task-Manager durchgängig volle 100% verzeichnet.



Nun also zum Vergleich der CPU-Last unter verschiedenen Stressoren:

Die Balken zeigen hier wieder den jeweiligen Mittelwert nach 30min Belastung. Zusätzlich wird mit begrenzten Linien, die symmetrisch um den Endpunkt eines Balkens angeordnet sind, die Standardabweichung s veranschaulicht. Dieses Streuungsmaß hilft zu unterscheiden zwischen Stressoren, die die CPU relativ gleichmäßig belasten (s = niedrig) und solchen, die das Testsystem durch häufig und/oder stark wechselnde Last beanspruchen (s = hoch).
Grob könnte man also zwei Gruppen von Stressoren unterscheiden: "brachiale Dauerquäler" wie etwa BurnMax oder CPUburn und mehr oder minder "fiese Stichler" wie der ja regelmäßig kurz pausierende 3dMark oder die beiden Pi-Cruncher oder der Toaster der Tweakers4u. "Dauerquäler" dürften dabei meines Erachtens am schnellsten eine unzureichende Spannungsversorgung, unzureichende Kühlung oder Fehler im Cache-/Ram-System aufdecken. Die "Stichler" dagegen, die ja allesamt keine berauschende Spitzenbelastung erreichen, sollten v.a. schwachbrüstige Spannungsregulatoren des Mainboards entlarven helfen, v.a. in overclockten Systemen. Aber zur Interpretation der Ergebnisse gibt es hier sicher versiertere und ganz bestimmt tiefschürfende Techniker


1.3 Einfluss auf die Vcore:

Nachfolgendes Diagramm zeigt den Einfluss der Stressoren auf die Vcore. Betrachtet es als kleines Extra, das nur am Rande mit dem Thema zu tun hat. Ich beoabachtete den Effekt bei allen meinen bisherigen Mainboards, die über entsprechende Sensoren verfügen: je höher die Last, umso niedriger die Vcore. Asus-Boards sagt man nach, dass dieser Zusammenhang dort besonders deutlich werde - und in der Tat baute das Testsystem hier ja auf einem ASUS P4PE auf.


Auch hier zeigt der CPU-Schocker BurnMax neuerlich seine Zähne. Neben dem niedrigsten Mittelwert, trotzte er dem P4PE ein Unterschreiten der auf 1,525V eingestellten Vcore ab: Lediglich BurnMax und Prime95 (Modi Blend und In-pl lFFT) provozierten kurzzeitig absolute Minima von 1,50V...

Man darf wieder spekulieren: Macht womöglich die gegenüber anderen Fabrikaten gewöhnlich kleiner dimensionierte und weniger aufwändig gestaltete Spannungsregelung der ASUS-Boards ihr immer wieder beobachtetes deutliches Overvolting der CPU im Ruhezustand notwendig?

/edit: Habe die beiden Vergleichsdiagramme zu Temperatur und CPU-Last aktualisiert, da sich einige Zahlendreher eingeschlichen hatten. Naja, ist offenbar niemandem aufgefallen.

[chrom]

2. Verlauf von CPU- und Mobo-Temperatur und CPU-Last:

Ich beschränke mich hier auf eine Auswahl der getesteten Stressoren. Besteht Bedarf nach mehr, kann ich entsprechende Grafiken irgendwann einmal nachliefern.


2.1 BurnMax:

Unser Spitzenreiter bei Temperaturmessung, CPU-Last und Vcore-Minderung darf in der Auswahl freilich nicht fehlen. Der Stressor setzt hier wie bei den folgenden Diagrammen nach 30s ein, während derer das System bei stabil 41°C CPU- und 33°C Mainboard-Temperatur bleiben musste. BurnMax setzt dann brachial ein und hält sein hohes Belastungsniveau bis zum Ende. Kein anderer Stressor erreichte einen derart steilen Anstieg der Prozessortemperatur. Hölle... Ein gutes Beispiel also für einen "Dauerquäler".


2.2 Prime95:

Worin demgegenüber die spezifischen Qualitäten der Dauerempfehlung aller OC-Foren Prime95 liegt, muss anhand des Diagramms unbeantwortet bleiben: Weder entwickelt es Spitzenleistungen als Dauerquäler, noch offenbart es sich als kleiner "Stichler". Nicht Fisch, nicht Fleisch. Ein klarer Pluspunkt bleibt aber die Überprüfung errechneter Werte im Torture-Test. Bei diesem Stressor muss man also nicht erst auf den - im Falle einer AMD/VIA-Kombi sicher wenig aussagekräftigen - Kollaps des Systems warten, sondern erhält eine dezente Fehlermeldung. Wahrscheinlich erklärt das auch seine Beliebtheit.


2.3 Windows-Taschenrechner:

Die c't empfiehlt es ja regelmäßig: Windows-Taschenrechner starten, auf die "wissenschaftliche Ansicht" umschalten, eine vielstellige Zahl eingeben und dann den Button "n!" anklicken. Windows moniert zwar rasch, "Der angeforderte Vorgang kann sehr viel Zeit in Anspruch nehmen" und bietet ein Anhalten an. Aber auch wenn man nicht auf "Fortsetzen" klickt, wird die CPU weiterhin belastet. Und zwar ordentlich: Nominell übertrifft der Taschenrechner dabei sogar Prime95, erreicht aber nicht ganz so hohe Temperaturen. Das Schöne ist, dass dieses Programm standardmäßig auf fast jedem Windows-Rechner installiert ist. So kann man z.B. beim Notebook-Kauf schon beim Händler überprüfen, ob es auch wirklich ruhig seinen Dienst versehen wird.


2.4 3Dmark2001SE:

Der 3DMark ist ja eigentlich eher als Grafik-Bench etabliert, beanspruchte aber auch deutlich den Rest des Testsystems. Eine gewisse Stärke stellt dabei die je kurz unterbrochene Abfolge verschieden rechenintensiver Anforderungen dar. Von der gestauchten Darstellung sollte man sich aber nicht täuschen lassen: Die Subtests des 3DMark erzeugen durchweg über ca. 30s bis 2min relativ stabile Last, die dann beim Wechsel auf den nächsten Subtest für ca. 2-10s auf ~10% abfällt. Es handelt sich hier also am ehesten um einen recht trägen Stichler. Wie am wiederkehrenden Muster der CPU-Last leicht ersehen werden kann, wurde der Bench im Loop-Modus mehrfach hintereinander durchgeführt. Welche Subtests dabei nun besonders rechenintensiv waren, habe ich inzwischen leider vergessen... ok... ich bin zu faul, nachzusehen...


2.5 SuperPi:

Wer's nervöser mag, wird hier bedient: ein Stichler. Vergesst aber bitte nicht, dass dieser Pi-Cruncher schon knappe 9 Jahre auf dem Buckel hat. Direkte Konkurrenten wie das ebenfalls getestete PiFast gehen wesentlich schneller zu Werke, erzeugen mehr Last und Temperatur. Welcher OC-Gott in den letzten Jahren diesen Dinosaurier wieder ausgegraben hat, blieb mir verborgen. Allerdings zeugte er damit einen unverbrüchlichen Mythos, der manche dünnbrettbohrenden Übertakter nun glauben lässt, SuperPi sei die legitime zweite Chance für ihr eigentlich uneigentlich instabiles System: Wenn Prime95 irgendwelche unerklärlichen Fehler ausspuckt, schmeißen sie eben SuperPi an, rechnen 1 oder 10M und fragen dann in irgendwelchen Foren nach, ob Prime95 nicht einen Programmierfehler enthalte... eine unselige Entwicklung. Aber hey... dieser Veteran brachte mein nagelneues Netzteil (gut... vielleicht war's auch 'was am Mobo) zum Zwitschern - was auch immer das bedeuten mag. Die Spannungen jedenfalls blieben stabil.


2.6 Tweakers4U-Toaster:

Vielleicht findet ja mancher SuperPi-Jünger im Toaster einen moderneren Ersatz, der obendrein ein wenig Bedienungskomfort bietet. Rangiert er hinsichtlich Last, Temperaturen und Vcore-Minderung auch durchweg auf den letzten Plätzen, sind die hochfrequenten Lastwechsel doch beeindruckend... vielleicht könnt Ihr sie sogar hören (sic!).


2.7 SETI:

Zum Schluss noch ein Wörtchen zu SETI: Zwar legt es beachtlich los, entwickelt dann aber nur noch mäßigen Stress. Wer meint, damit sein System schon am Limit zu bewegen, sollte vielleicht doch noch einmal potentere Stressoren testen. Zwar habe ich diese Abbildungen irgendwann schon einmal hier gezeigt, aber der Vollständigkeit halber noch einmal: Hier findet ihr eine gestauchtere Darstellung des Verlaufs über die vollen >3h, die mein Rechner für eine WU benötigte.

/edit: Windows-Taschenrechner eingefügt

[chrom]

3. Details zum Testaufbau:

Da das wahrscheintlich ohnehin die wenigsten interessiert, habe ich es ans Ende verschoben.

3.1 Messinstrumente:

A) Hardware-Monitoring:
Neben den Temperaturen von CPU und Mainboard wurden auch die Spannungen der +12V-, +5V- und +3,3V-Leitungen sowie VCore und Lüfterdrehzahlen mit dem Motherboard Monitor 5 (MBM 5.3.4.0) im 1-Sekunden-Intervall gemessen. Die integrierte Logging-Funktion ("Intervall-Log") des MBM ist auf unzureichende 1000 Messwerte limitiert und arbeitet durch die fortlaufende zeitlich absteigende Sortierung der Einträge relativ träge. Als Alternative wählte ich für die automatisierte Protokollierung das MBM-Plugin SimpleLogger.
Wie sich später herausstellte, war das eine eher unglückliche Wahl, da der SimpleLogger aus nicht näher überprüften Gründen (Overclocking? Programmfehler?) mit und ohne Systemlast regelmäßig Daten unterschlug (vgl. 3.2).

B) CPU-Last:
Wie zuvor schon erläutert, wurde die CPU-Last als "µop-retired" ebenfalls im Sekundetakt durch das Tool Perfwatch 1.3 mitgeschnitten.

C) Umgebungstemperatur:
Mit einem handelsübliches Digitalthermometer auf dem Schreibtisch bestimmte ich die Umgebungstemperatur vor und während der Tests. Sie schwankte über den gesamten Zeitraum zwischen 22,5°C und 23,5°C - mehr Konstanz war mit Zentralheizung nicht zu erreichen. Unnötig zu erwähnen, dass im heimischen Wohnzimmer Laborbedingungen aber ohnehin nicht simuliert werden können.


3.2 Messfehler und Korrekturen:

PerfWatch, MBM/SimpleLogger und der Teetimer, den ich zur Zeitmessung benötigte, verbrauchen natürlich auch selbst eine gewisse Rechenzeit. Im Idle-Modus zeigte PerfWatch bei aktiviertem SimpleLogger inkl. laufendem Teetimer und einigen anderen Hintergrundprogrammen ca. 0,2-0,3% Auslastung. Ohne es genau zu wissen, nehme ich an, dass darin bereits der eigene Verbrauch der PerfWatch enthalten ist. Bei parallel laufendem Stressor wurde die Ressource Rechenzeit offenbar dennoch zeitweise sehr knapp: So kam es vor, dass für jeweils 1-2s ganze Wertereihen nicht im Log-File verzeichnet wurden (= Werte-Auslassungen) oder dass innerhalb eines Sekundenintervalls mehr als eine Wertereihe abgelegt wurde (= Zeitliche Stauchung).

Werte-Auslassungen:
Die bereits angesprochene Neigung des SimpleLoggers, in annähernd regelmäßigen Abständen für eine Sekunde die Datenausgabe zu verweigern, wurde durch manche Stressoren noch verschlimmert. Auch die PerfWatch blieb davon nicht ganz verschont: Beim Anlaufen von RealStorm leistete sich das sonst durchweg solide Instrument einen Aussetzer - es blieb der einzige, der noch dazu außerhalb des Zeitraums für die statistische Analyse lag.
Bei der Synchronisation der Daten des SimpleLoggers mit jenen der PerfWatch wurden ausgelassene Werte zeitsynchron als fehlende Werte kodiert. Die Anzahl fehlender Werte erreichte beim RealStorm Benchmark mit 250 von 1800 Messwerten ein Maximum, überschritt bei allen anderen Stressoren nicht die Anzahl von 60. Sie flossen freilich nicht in die weitere Statistik ein, reduzierten lediglich einen relativ üppigen Stichprobenumfang.

Zeitliche Stauchung:
Dieses Phänomen betraf wiederum beide Instrumente. PerfWatch setzte vor allem der Parallelbetrieb mit StressCPU zu: Statt wie gewohnt eine Wertereihe zu jeder Sekunde zu liefern, wurden über eine längere Etappe nunmehr alle zwei Sekunden Werte ausgegeben, dann auch gleich zwei je Sekunde. MBM/SimpleLogger zeigte diese Stauchung zeitbezogener Daten in größerem Ausmaß und geradezu systematisch unter allen Stressoren. Korrigierend wurden dann die jeweils zweiten Wertereihen eines Sekundenintervalls auf das ausgelassene vorausgehende manuell verteilt: Aus "Zeit1-Data1, Zeit3-Data2, Zeit3-Data3" wurde also "Zeit1-Data1, Zeit2-Data2, Zeit3-Data3"


3.3 Testsystem:

Hardware:
- CPU: Intel Pentium 4 1800a @ 2430 MHz (bei eingestellten 1,525V VCore)
- Mainboard: Asus P4PE (SATA, FW, S, L), BIOS 1002
- RAM: 512 MB DDR333, Takt 180 MHz (DDR 360), Timing 2,5-3-3-7, VDimm 2,6V
- CPU-Kühlung: Zalman CNPS 7000 AlCu (Drehzahl: 1420 +/- 50 U/min)
- Gehäuselüfter: 2 x 12cm (Front: 810 +/- 10 U/min; Heck: 755 +/- 15 U/min)
- Lüftersteuerung
- Gehäuse: Compucase 6920
- Netzteil: BeQuiet BQT P4-400W-S1.3 (1 Lüfter)
- Grafikkarte: ManLi Radeon 9000 64MB 4xAGP
- PCI: Tekram DC395U, Eicon DIVA ADSL PCI, NoName USB2.0-AddOn-Card
- Festplatte: Samsung SP1604N (160GB, 7200 U/min)
- ATAPI: Toshiba SD-M1712, Teac CD-W548E

Software:
- OS: MS Windows 2000 SP4 inkl. Hotfixes
- Teetimer: Countdown / Zeitmessung
- MBM5/-SimpleLogger: Hardware-Monitoring
- PerfWatch 1.3: CPU-Last

Während der Tests blieb der Virenscanner deaktiviert und sämtliche Energiesparoptionen wurden auf unkritische Einstellungen zurückgesetzt. Es liefen keine Last-erzeugenden Hintergrundprogramme.


3.4 Testablauf:

Nach Kontrolle der Umgebungstemperatur (23°C +/- 0,5°C) wurden die Tools zur Zeitmessung und zur Protokollierung der Hardwareparameter und der CPU-Auslastung gestartet. Idle musste das System dann über mindestens eine Minute bei stabil 41°C CPU- und 33°C Mainboard-Temperatur bleiben - 3 Ausreißer wurden noch geduldet. Der dann aktivierte Stressor wurde durchweg mit möglichst niedriger Priorität betrieben, also wo möglich im Hintergrund ausgeführt, etwa auf die Taskleiste oder in den System-Tray minimiert. Im Vordergrund lief stets der Teetimer. Ausnahmen: 3Dmark2001 und RealStorm Benchmark 2004 erzwingen sich die Vollbilddarstellung.


3.5 Auswertung:

Für alle Variablen wurden über die untersuchte Zeitspanne von 30min Arithmetisches Mittel, Standardabweichung (s), Modalwert, Minimum, Maximum, relative Häufigkeiten von Modalwert und Maximum sowie der Stichprobenumfang inkl. fehlender Werte bestimmt. Der Nullpunkt der Zeitreihe einer Variable wurde dabei jeweils so gelegt, dass er mit der einsetzenden Wirkung eines Stressors zusammenfiel: Kriterium war dabei die Ausprägung von "µop-retired", die 10% übersteigen musste.
Berechnete Korrelationskoeffizienten zeigten keine substantiellen Zusammenhänge zwischen CPU-Last und Vcore oder Temperatur, was am ehesten mit der unterschiedlichen Trägheit von Sensoren, der unterschiedlichen Dynamik (z.B. relativ träger Temperaturanstieg bei sofort einsetzender Last) und dem hohen Stichprobenumfang mit damit verbundener Tendenz zur Mitte erklärt werden kann.

Datenumfang Mittelwerte vs. Diagramme:
Während in die Berechnung der statistischen Kennwerte also nur Daten unter Stressor-Einwirkung einflossen, habe ich für eine bessere Darstellung des Anstiegs von CPU-Temperatur und -Last die Verlaufs-Diagramme um die Daten aus den 30s-Idle-Betrieb unmittelbar vor Einsetzen der Last ergänzt. Eine Zeitreihe startet in Verlaufs-Diagrammen also 30 Sekunden früher (!).

[chrom]

4. Danke!

Tja... geschafft! Dank an all jene, die sich wirklich durch den ganzen Text gezwungen haben und damit meinen vertendelten Nachmittag rechtfertigen helfen! Ein besonderer Dank geht an den Autor von PerfWatch Matthias Withopf, der mir mit einer aufgebohrten Version seines Tools ein sekundengenaues Last-Protokoll ermöglichte.

Eine Zusammenfassung erspare ich mir an dieser Stelle. Es gilt schließlich nicht einen Testsieger zu küren oder andere Abarten der ComputerBild zu imitieren.

[sloppydirk]

Respekt !

[janerik]

...

[cRoMaN]

@chrome: Solche Leute, wie du es bist, machen dieses Forum einfach einzigartig.

[Lumpi]

wow ,
superklasse, das stellt alles bisher dagewesene in den Schatten!

[grandmasterw]

Jo, das is spitze. Da sollt ich glatt mal den P4 meiner Schwester anheizen.
So gehört sichs, ich sollt mich eigentlich schämen, als Secondary Master hab ich noch kein einziges Review geschrieben. Aber in letzter zeit hab ich so gut wie keine neue Hardware gekauft.
Aber jeder, der gern ein Review machen möchte, darf! Auch wenn er noch recht neu ist, keine falsche Scheu.

[chrom]

danke, leute!

vielleicht sollte ich noch einmal betonen, dass sich meine ergebnisse ausdrücklich nur auf die p4-familie beziehen. wie intensiv einzelne stressoren cpu-last etwa in einem athlon-system erzeugen, lässt sich mit perfwatch nun einmal nicht bestimmen. da aber burnK7, ein auf athlons spezialisiertes cpuburn-modul, hohe last auf dem p4 erzeugen kann, sollte man im umkehrschluss annehmen dürfen, dass hochpotente p4-quäler auch den amds einheizen dürften.

jetzt will ich euch aber noch kurz einen screenie vom relativ unbekannten spitzenreiter aller vergleichs-kategorien burnmax zeigen:

wie ihr seht, kann man die last auch auf die einzelnen cpus eines dual-systems verteilen. das dürfte dann auch für ht funktionieren, auch wenn es kaum sinn macht... also testen!

und noch ein wort zur kandidaten-auswahl. einige weitere tools hatte ich noch angetestet:
- Hot CPU Tester Pro 4 LE
das hier interessierende burn-in-modul dieser umfangreicheren system-test-suite zog so viel rechenzeit an sich, dass die automatisierte Protokollierung von cpu-auslastung und -temperatur nachhaltig behindert wurde. es ließ sich auch nicht niedriger priorisieren.
- CPU Stability Test 5.0
auf dieses inzwischen nicht mehr fortentwickelte tool wurde ich erst aufmerksam, als der großteil der tests bereits abgeschlossen war. Nachdem anhand der zu verzeichnenden cpu-last (maximum nach 30 min: ~ 38%) kein neuer rekord zu erwarten war, sparte ich mir kurzentschlossen weiteren aufwand.
-HeavyLoad 2.0 beta 3
ähnliches hier: last meist nur zwischen 10 und 20%

[chrom]

Ergänzung zur Vcore-Minderung unter Last:

Da man im Verlauf die Wirkung der Prozessorlast auf die Vcore des P4PE besser erkennen kann, lege ich noch einmal nach. Zwei Diagramme zu Stressoren, die relativ spezifisch nur die CPU auslasten, aber das stabil ("Dauerquäler"):


Man sieht gleich, dass das P4PE idle die Vcore um 5-6% überhöht. MBM Heatup setzt zur 30. Sekunde ein und erreicht quasi sofort ein recht stabiles Belastungs-Niveau von ca. 20%: Dies quittiert das P4PE mit einer Minderung der Vcore, die aber immer noch um ca. 3% über dem eingestellten Nominalwert (1,525V) bleibt.


Ähnlich aber ausgeprägter reagiert das Mobo unter der heftigeren Belastung die BurnMax freisetzt: idle ist die Vcore um 5-6% erhöht, mit Einsetzen des Stressors pendelt sie sich etwa auf den Sollwert ein. BurnMax erreicht mit der 30. Sekunde ein Niveau von 78-86% CPU-Last.

Ich möchte fast wetten, dass Rio mit seiner Epox-Flotte kaum derartig deutliche Vcore-Veränderungen bei Last hinnehmen muss...

[pugnacity]

not bad man.... ich habe das zwar gerade nur flüchtig gelesen, aber ich muss schon sagen das is richtig gut....
werde mir das morgen in aller ruhe reinziehen

[Predator]

Gebührt absoluten Respekt, so ein "Review" dauert sicherlich verdammt lange - zumal ich zugeben muss, dass ich niemals solch große Unterschiede erwartet habe.

[janerik]

...

[chrom]

@janerik: es ist wichtig, immer nur einen stressor laufen zu lassen, damit sie sich nicht gegenseitig die ressourcen stehlen. da hilft auch eine höhere priorität nur bedingt. ich empfehle dir also, burnmax einmal ohne weitere tasks im idle-modus zu starten und 5min abzuwarten... nach ca. 10min sollte der pc seine max. temp. erreicht haben, wenn er's übersteht...