E545 AMD A-Serie APU AB-4500M Quadcore 4x1,9 GHz Linux hohe Last, Lüfter nie zu hören

[dankobum]

Ich habe beim E545 mit AMD A-Serie APU AB-4500M Quadcore 4x1,9 GHz unter XUbuntu-Linux 14.04 mit xfce4-Desktop einen Belastungstest gemacht mit folgenden Anwendungen:

- 6 x vlc mit Wiedergabe eines .mpg-Videos
- Libre-Office-Calc mit Tabelle
- firefox mit webseite
- download von grosser Datei mit Firefox
- mp3-Abspielen eines Albums
- Thunderbird geöffnet

Die load average in top war bei der ersten Zahl immer über einem Wert von 2, die kurzfristige load war auch teilweise über 3. Aber: der Lüfter ist die ganze Zeit nicht zu hören und das Notebook schafft auch alle Anwendungen, also z.B. keine Ruckler bei der .mpg-Wiedergabe mit dem vlc.

Ist das normal so? Ist unter Windows der Lüfter manchmal zu hören?

 

[yatpu]

ein lasttest sieht eigentlich anders aus.
ich würde zu mprime greifen. in der windowswelt kennt man das programm als prime95. damit bringst du die cpu ins schwitzen und forderst den kühler.

 

[blafoo]

Zumal ein hoher Load nicht zwangsläufig auf viel CPU-Last zurückschließen muss.

Mprime brauchst du noch nich mal

Du hast 4 Cores?:

cat /dev/urandom > /dev/null

Produziert 100% Last

Das ganze 4 x ausführen und schon hast du alle 4 Kerne auf 100%.

Alternativ gibts dazu wie oben genannt halt mprime, welches aber hauptsächlich dafür gedacht ist Stabilität bei Übertaktern zu sichern, oder CPUBurn.

Grüße

 

[dankobum]

Zumal ein hoher Load nicht zwangsläufig auf viel CPU-Last zurückschließen muss.

Mprime brauchst du noch nich mal

Du hast 4 Cores?:

cat /dev/urandom > /dev/null

Produziert 100% Last

Das ganze 4 x ausführen und schon hast du alle 4 Kerne auf 100%.

Alternativ gibts dazu wie oben genannt halt mprime, welches aber hauptsächlich dafür gedacht ist Stabilität bei Übertaktern zu sichern, oder CPUBurn.

Grüße

Habe ich gemacht und top sagt:

top - 19:42:09 up 2:12, 6 users, load average: 8,14, 8,52, 5,18

Vorhin war der erste Wert sogar über 18. Aber der Lüfter ist weiterhin nicht zu hören. Die 4 Befehle habe zusätzlich zum ersten Test ausgeführt, immerhin ruckelten dann die vlc-Videos. Der Prozessor war also wirklich an der Belastungsgrenze.

 

[blafoo]

Gut und die Temperatur ueberpruefst du dann mit lm_sensors. Gruesse

 

[dankobum]

lm-sensors heisst das Paket und nicht lm_sensors. Habe es installiert und "sensors" gibt nur die Temperatur von pci-Dingern aber nicht von der CPU.

 

[blafoo]

Durchgelesen wie man es einrichtet?

sensors-detect

ausgeführt?

 

[dankobum]

Durchgelesen wie man es einrichtet?

 sensors-detect

ausgeführt?

Damit komme ich nicht weiter:




Sorry, no sensors were detected.
This is relatively common on laptops, where thermal management is
handled by ACPI rather than the OS.




Some south bridges, CPUs or memory controllers contain embedded sensors.
Do you want to scan for them? This is totally safe. (YES/no): YES


Und hier kamen dann nur Ausgaben mit "No", auch für die CPU.


Habe auch schon gegooglet aber bin bisher nicht fündig geworden.

 

[dankobum]

Immerhin nach nun ca. 1 Stunde mit den 4 mal
cat /dev/urandom > /dev/null

sagt top:

top - 20:45:24 up 3:16, 7 users, load average: 4,50, 4,80, 4,67

Und ich höre ganz leise den Lüfter, aber wirklich super leise, nur etwas lauter als ohne viel Last. Scheint so normal zu sein bei diesem Notebook, finde ich super.

 

[dankobum]

Vielen Dank für super gute Hilfe hier.

 

[hikaru]

Wie blafoo schon schrieb ist der Load kein(!) Indiz für die CPU-Auslastung (Usage). Ganz im Gegenteil, es ist ein Zeichen dafür, dass die CPU auf etwas wartet und daher selbst wenig zu tun hat.
Daher wäre, wie von yatpu vorgeschlagen mprime der bessere Benchmark.

Mprime brauchst du noch nich mal

Du hast 4 Cores?:

cat /dev/urandom > /dev/null

Produziert 100% Last

Das produziert je nach Ausgangssituation (Füllstand des Entropiepools) nicht 100% Auslastung (Usage) sondern Load, da die CPU darauf wartet bis der Entropiepool wieder gefüllt ist, was bei /dev/urandom sehr lange dauern kann. Daher ist /dev/urandom hier die schlechteste Wahl.
Wenn du deinen Input stattdessen aus /dev/zero holst erreichst du tatsächlich 100% Auslastung auf einem Kern.
Das Ergebnis ist bei entsprechender Threadzahl belastungstechnisch fast vergleichbar mit mprime. Fast deshalb, weil cat nur die ALU, aber nicht die FPU belastet. Je nach CPU-Modell sind die resultierenden Temperaturunterschiede vernachlässigbar bis deutlich.

 

[dankobum]

Wenn du deinen Input stattdessen aus /dev/zero holst erreichst du tatsächlich 100% Auslastung auf einem Kern.

Ich habe das mit 4 mal cat /dev/urandom > /dev/null im top natürlich kontrolliert: 4 cat Prozesse im top, die jeweils einen Kern zu 98 - 100 % auslasteten.

Jetzt gerade läuft dein Vorschlag mit 4 mal
cat /dev/zero > /dev/null

Ich sehe im Moment noch keinen grossen Unterschied (4 cat Prozesse oben im top, die jeweils einen Kern fast voll auslasten). Der Lüfter ist vielleicht etwas lauter als gestern. Ich lasse das so jetzt mal für einige Zeit laufen und beobachte das.

 

[hikaru]

Wie gesagt, es kommt auf die Umgebungsbedingungen an wie schnell /dev/urandom Daten liefert.
Im Gegensatz zu /dev/random steckt dahinter nämlich kein Pseudozufallszahlengenerator der im Grunde nur durch deine CPU-Leistung begrenzt wird sondern idealerweise* tatsächliche Zufallszahlen, was in erster Linie Nutzereingaben (Tastaturanschläge, Mausbewegungen), aber je nach Implementation auch Sensoren sind. Und da du nicht ansatzweise in Echtzeit so viel Maus schubsen kannst wie cat Bytes aus dem Puffer zieht kann der Puffer auch mal leer laufen woraufhin das Device ohne zu terminieren stehenbleibt.
Das wird naturgemäß auf einem lange laufenden System später passieren als auf einem Frisch gebooteten System das nur auf Eingaben wartet.

Wenn man nicht auf echte* Zufallszahlen angewiesen ist sollte man daher darauf verzichten /dev/urandom zu verwenden, da man einerseits die "wertvollen" Zufallszahlen vielleicht woanders dringender braucht und andererseits das Device eben nicht echtzeitfähig ist was je nach Anwendung kritisch sein kann.


*) Wie "zufällig" und damit unvorhersehbar diese Inputs tatsächlich sind ist Gegenstand hitziger akademischer Diskussionen.

 

[yatpu]

/dev/random blockiert bei unzureichend gefülltem entropie-pool, /dev/urandom dagegen nicht, da /dev/urandom einen datensatz aus dem entropie-pool immer weiter verarbeitet (hasht?). dadurch bekommt man von urandom immer daten geliefert, deren qualität nicht so gut wie die aus /dev/random ist.
https://de.wikipedia.org/wiki//dev/random#.2Fdev.2Furandom

lesenswert ist auch https://de.wikipedia.org/wiki/Load
-> ein hoher load-wert sagt nichts über die auslastung der cpu aus.

 

[hikaru]

/dev/random blockiert bei unzureichend gefülltem entropie-pool, /dev/urandom dagegen nicht

Huch! Da habe ich die beiden doch tatsächlich verwechselt. :facepalm:
Ich nehme alles zurück und behaupte das Gegenteil.

Danke yatpu!

 

[blafoo]

 

[dankobum]

Gestern habe ich mit einem Bekannten telefoniert und ihm die ganze Sache hier erzählt. Er meinte, AMD kann auch nicht zaubern. Wenn der Lüfter wirklich so leise ist und auch keine merkbar heisse Luft an der Seite rauskommt bei obiger Belastung, dann ist die CPU sehr wahrscheinlich unter diesem Linux fest in der Einstellung, wo möglichst wenig Energie verbraucht wird und nicht die volle Leistungsfähigkeit aberufen wird.

In der Produktbeschreibung steht:
"Prozessor: AMD A8-4500M Quad-Core Prozessor mit 1.90 GHz und 4 MB L2 Cache (bis zu 2.80 GHz mit AMD Turbo Core 3.0 Technologie)"

Ich vermute, das Xubuntu 14.04 unterstützt dieses Turbo-Feature nicht. Kennt sich jemand damit aus?

Wie ist das eigentlich bei den Windowsnutztern, die dieses Gerät haben, wie verhält sich da der Lüfter?

 

[blafoo]

Doch doch das kann sein .. die gesammte APU wird mit 35Watt beziffert.

D.h. wenn du CPU + GPU voll! auslastet (zb. hiermit: http://unigine.com/products/heaven/) wird das Mopped wohl auch wirklich warm

Ich denke, reines Bauchgefühl, das die CPU vllt 15W von der APU braucht.

Und das kann fast semipassiv gekühlt werden.

Zum Boost: Mit den Intels ist es wie folgt:

Wird 1 Kern belastet geht dieser (in meinem Fall) auf fast 3GHz (von 2,2) hoch.
Werden 2 Kerne belastet gehen diese auf 2,6 oder 2,8 GHz.
Werden alle 4 Kerne belastet ist kein Boost vorhanden.

So wird es bei AMD auch sein.

Ich kontrolliere es unter LInux wie folgt:

cat /proc/cpuinfo  | grep MHz

Es gab mal einen Ausgabe-Bug, dann hast du nur daran gesehen das der Turbo an ist wenn da anstelle von 1900,73 MHz (z.B) 1901,00 MHz stand. Er hat den Turbo als +1MHz angezeigt.

Das denke ich wird bei dem AMD nicht anders sein.

Kannst ja mal nen cpuinfo schauen wenn alle 4 Cores belegt sind (4 x cat urandom) und wieviel angezeigt wird wenn du es nur 1 x startest.

Grüße