Mein Ziel ist es, einen Mini-Server (nicht HTPC) mit geringem Stromverbrauch im Leerlaufmodus einzurichten, der jedoch bei Verwendung eine gute Leistung bietet. Der Fokus liegt mehr auf Datensicherheit als auf Verfügbarkeit. Mit anderen Worten: Qualitätsteile, aber Redundanz nur für die Lagerung.

Ohne mich als voreingenommen zu betrachten, hatte ich nach einigen Recherchen das Gefühl, dass einige AMD-Desktop-APUs einen guten Wert bieten würden.

Die verbleibenden Fragen sind:

• Wird der Leerlaufzustand der GPU den Stromverbrauch senken und Ressourcen für die CPU freisetzen?
• Führen Cool'n'Quiet und Turbo Core im Leerlauf zu dem beabsichtigten geringen Stromverbrauch, aber zur Leistung unter Last?
• Wird Linux dieses Szenario wie beabsichtigt unterstützen? Nicht wenige Fragen und Forumsdiskussionen scheinen darauf hinzudeuten, dass dies nicht unbedingt der Fall ist.

[Bearbeiten: Abschließende Gedanken zur Prozessorauswahl]

• AMD gegen AMD:
  • Richland macht hier einen viel besseren Job als Trinity.
  • Kaveri kann (zumindest vorerst) nicht mit Richlands Verlustleistung im Leerlauf mithalten.
  • Die GPU des A10-6700 ist möglicherweise überbewertet, aber es ist ein bisschen traurig, dass sie nicht viel verwendet wird. Einige Algorithmen können möglicherweise ihre Rechenleistung einsetzen. Keine Ahnung, wie sich das auf den Stromverbrauch des Prozessors auswirkt.
  • Ich vermute, dass der A10-6790K der gleiche Prozessor wie der A10-6700 ist, mit nur einem anderen Parametersatz für Turbo Core-Boosts. In diesem Fall kann der A10-6790K aufgrund seiner höheren TDP länger anheben und / oder langfristig höhere Frequenzen liefern. Dafür benötigen Sie jedoch einen anderen CPU-Lüfter (denken Sie an Platz und Temperatur / Lebensdauer).
• AMD A10-6700 gegen Intel Core i3-3220:
  • Der A10-6700 hat viel mehr GPU-Leistung, die hier nicht genutzt wird.
  • Der i3-3220 hat eine geringere Verlustleistung im Leerlaufmodus.
  • Während in typischen Benchmarks der i3-3220 für Berechnungen schneller ist, kann ich nicht sehen, wie seine zwei Hyper-Threading-Kerne parallele Anforderungen (z. B. an eine Datenbank mit Web-Frontends) so schnell wie mindestens vier voll funktionsfähige Kerne verarbeiten können bei der Annahme eines ernsthaften Caching). Ich habe jedoch keine ernsthaften Benchmarks gefunden - nur einige Hinweise.

[Bearbeiten: Der bapmParameter des kostenlosen Radeon-Treibers ist standardmäßig für Kaveri, Kabini und Desktop Trinity, Richland-Systeme ab Linux 3.16 festgelegt.]

Siehe [pull] radeon drm-fixes-3.16 .

In Bezug auf Debian auf 3.16-Basis scheinen die Standardeinstellungen (noch?) Nicht zu funktionieren, während der Boot-Parameter dies tut. Siehe Einrichten eines Debian-Systems (Fokus auf 2D oder Konsole / Server) mit einer AMD Turbo Core-APU für maximale Energie und Recheneffizienz.

[Bearbeiten: Der kostenlose Radeon-Treiber wird bald einen bapmParameter haben]

Da das Fazit darin besteht, eine gepatchte Version des kostenlosen radeonTreibers mit Ihrer APU zu verwenden, um Turbo Core zu unterstützen und das Beste daraus zu machen (außer 3D-Grafiken), wenn Sie können (das Aktivieren bapmkann in einigen Konfigurationen zu Instabilitäten führen ), es ist eine gute Nachricht, dass zukünftige Versionen von Radeon einen Parameter haben werden, um bapm zu aktivieren .

[Originaler Beitrag folgt]

AMD A10-6700 (Richland) APU Erfahrung

Prozessorauswahl

Mein erster PC war ein 486DX2-66, der aus Dutzenden von 3,5-Zoll-Disketten mit Slackware-Quellpaketen eingerichtet wurde. Nun, viele Dinge haben sich geändert, und viele Branchen scheinen sich derzeit in der Phase zu befinden, in der sie die Anzahl noch erhöhen von Produktvarianten.

Dieser Umstand und einige der unglücklichen Entscheidungen von AMD in der jüngeren Vergangenheit haben es mir nicht leichter gemacht, mich für eine Plattform für einen Miniserver zu entscheiden. Aber schließlich entschied ich, dass der A10-6700 eine gute Wahl sein würde:

• Mehrere Bewertungen haben gezeigt, dass ein (noch weitgehend nicht verfügbarer) Kaveri im Leerlauf mehr Strom verbraucht als ein Richland oder ein Trinity
• Der Vorteil des Richland A10-6700 gegenüber dem Trinity A10-5700 scheint erheblich zu sein: niedrigerer und höherer höchster Frequenzbereich, feinkörnigerer Turbokern (auch unter Berücksichtigung der Temperatur - ein ziemlicher Vorteil, wenn die GPU im Leerlauf ist)
• Die GPU des A10-6700 soll überbewertet sein (Marketing-orientierte Benennung) und die Preisgestaltung der APU scheint fair zu sein

Andere Komponenten und Setup

Trotz der unzähligen Prozessoren stehen nicht viele Mini-ITX-Karten zur Verfügung. Der ASRock FM2A78M-ITX + schien eine vernünftige Wahl zu sein. Der Test wurde mit der Firmware V1.30 durchgeführt (keine Updates verfügbar, während ich dies schreibe).

Nur 80% der Nennleistung eines Netzteils sollten verbraucht werden. Auf der anderen Seite arbeiten viele unter 50% Last nicht effizient. Es ist sehr schwierig, eine energieeffiziente Stromversorgung für ein System mit einem geschätzten Verlustleistungsbereich von 35 W bis 120 W zu finden. Ich habe diese Tests mit einem Seasonic G360 80+ Gold durchgeführt, da er die meisten Wettbewerber hinsichtlich der Effizienz bei geringen Lasten übertrifft.

Zwei 8-GB-DDR3-1866-RAMs (als solche konfiguriert - was im Vergleich zu 1333 einen Unterschied macht), ein SSD-Laufwerk und ein CPU-Lüfter in PWM-Steuerfeldqualität waren ebenfalls Teil des Testaufbaus.

Die Messungen wurden mit einem AVM Fritz! DECT 200 durchgeführt, von dem berichtet wurde, dass er genaue Messungen durchführt. Die Plausibilität wurde jedoch mit einem älteren No-Name-Gerät überprüft. Es konnten keine Inkonsistenzen festgestellt werden. Die gemessene Verlustleistung des Systems umfasst den verringerten Wirkungsgrad des Netzteils für niedrigere Lasten.

Ein [W] QHD-Bildschirm wurde über HDMI angeschlossen.

Der anfängliche gemeinsam genutzte Speicher für die GPU wurde im UEFI-BIOS auf 32 MB festgelegt. Außerdem wurde die Onboard-GPU als primär ausgewählt und IOMMU aktiviert.

Es wurde kein X oder anderes grafisches System installiert oder konfiguriert. Die Videoausgabe war auf den Konsolenmodus beschränkt.

Grundlagen

Es gibt ein paar Dinge, die man wissen muss.

• Während die Entscheidung über Cool'n'Quiet von Software außerhalb der Prozessoren getroffen wird, ist Turbo Core eine Entscheidung, die autonom von einem zusätzlichen Mikrocontroller auf der APU (oder CPU) getroffen wird.
• Viele Werkzeuge sowie /procund /sysOrte berichten nicht Turbo Core - Aktivität. cpufreq-aperf, cpupower frequency-infoUnd cpupower monitortun, aber erst nach modprobe msr.

Testfallgruppe 1: Linux + Radeon

Ich habe mit neuem Arch Linux begonnen (Installer 2014.08.01, Kernel 3.15.7). Schlüsselfaktor ist hier das Vorhandensein von acpi_cpufreq(Kernel-CPU-Skalierung) und radeon(Kernel-GPU-Treiber) und die einfache Möglichkeit zum Patchen radeon.

Testfall 1.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting ............................ Aktiviert
UEFI BIOS Cool'n'Quiet-Einstellung .......................... Aktiviert
/ sys / device / system / cpu / cpufreq / boost ................... 1
/ sys / device / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequenz-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Beobachteter CPU-Bereich "/ proc / cpuinfo" ... 1800 - 3700
Beobachteter "cpupower monitor" Frequenzbereich ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... Leistungsstufe 0

Laden | Kernfrequenzen
--------------- + -----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Testfall 1.2: BIOS TC on - CnQ on / Linux Performance - Boost

UEFI BIOS Turbo Core Setting ............................ Aktiviert
UEFI BIOS Cool'n'Quiet-Einstellung .......................... Aktiviert
/ sys / device / system / cpu / cpufreq / boost ................... 1
/ sys / device / system / cpu / cpu * / cpufreq / scaling_governor ... Leistung 

"cpupower frequenz-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Beobachteter CPU-Bereich "/ proc / cpuinfo" ... 3700
Beobachteter "cpupower monitor" Frequenzbereich ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... Leistungsstufe 0

Laden | Kernfrequenzen
--------------- + -----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Testfallgruppe 1 Zusammenfassung

Turbo Core-basierte Boosts sind in diesem Szenario nicht möglich, da der radeonTreiber das bapmFlag derzeit aufgrund von Stabilitätsproblemen in einigen Szenarien deaktiviert . Daher wurden weitere Tests übersprungen.

Testfallgruppe 2: Linux + Bapm-gepatchte Radeon

Um zu ermöglichen bapm, begann ich mit einem frischen Arch Linux (installer 2014.08.01, Kernel 3.15.7), hat mich das core linuxPaket über ABS(3.15.8), die bearbeitet PKGBUILDzu verwenden pkgbase=linux-tc, zog die Quellen mit makepkg --nobuild, änderte sich pi->enable_bapm = true;in trinity_dpm_init()in src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.c, und kompilierte es mit makepkg --noextract. Dann habe ich es installiert ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzund pacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz) und aktualisiert GRUB( grub-mkconfig -o /boot/grub/grub.cfgaber natürlich YMMV).

Als Ergebnis hatte ich die Wahl, zu booten linuxoder linux-tc, und die folgenden Tests beziehen sich auf Letzteres.

Testfall 2.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting ............................ Aktiviert
UEFI BIOS Cool'n'Quiet-Einstellung .......................... Aktiviert
/ sys / device / system / cpu / cpufreq / boost ................... 1
/ sys / device / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequenz-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Beobachteter CPU-Bereich "/ proc / cpuinfo" ... 1800 - 3700
Beobachteter "cpupower monitor" Frequenzbereich ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... Leistungsstufe 0

Laden | Kernfrequenzen
--------------- + -----------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 4100
stress --cpu 3 | 3 x 4100 .. 3900
stress --cpu 4 | 4 x 4000 .. 3800

Testfall 2.2: BIOS TC on - CnQ on / Linux Performance - Boost

UEFI BIOS Turbo Core Setting ............................ Aktiviert
UEFI BIOS Cool'n'Quiet-Einstellung .......................... Aktiviert
/ sys / device / system / cpu / cpufreq / boost ................... 1
/ sys / device / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"cpupower frequenz-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Beobachteter CPU-Bereich "/ proc / cpuinfo" ... 3700
Beobachteter "cpupower monitor" Frequenzbereich ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... Leistungsstufe 0

Laden | Kernfrequenzen
--------------- + -----------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 4100
stress --cpu 3 | 3 x 4100 .. 3900
stress --cpu 4 | 4 x 4000 .. 3800

Testfall 2.3: BIOS TC on - CnQ on / Linux OnDemand - No Boost

UEFI BIOS Turbo Core Setting ............................ Aktiviert
UEFI BIOS Cool'n'Quiet-Einstellung .......................... Aktiviert
/ sys / device / system / cpu / cpufreq / boost ................... 0
/ sys / device / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand

"cpupower frequenz-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Beobachteter CPU-Bereich "/ proc / cpuinfo" ... 1800 - 3700
Beobachteter "cpupower monitor" Frequenzbereich ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... Leistungsstufe 1

Laden | Kernfrequenzen
--------------- + -----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Testfall 2.4: BIOS TC on - CnQ on / Linux-Leistung - kein Boost

UEFI BIOS Turbo Core Setting ............................ Aktiviert
UEFI BIOS Cool'n'Quiet-Einstellung .......................... Aktiviert
/ sys / device / system / cpu / cpufreq / boost ................... 0
/ sys / device / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"cpupower frequenz-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Beobachteter CPU-Bereich "/ proc / cpuinfo" ... 3700
Beobachteter "cpupower monitor" Frequenzbereich ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... Leistungsstufe 1

Laden | Kernfrequenzen
--------------- + -----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Testfall 2.5: BIOS TC aus - CnQ ein / Linux OnDemand - Boost

UEFI BIOS Turbo Core-Einstellung ............................ Deaktiviert
UEFI BIOS Cool'n'Quiet-Einstellung .......................... Aktiviert
/ sys / device / system / cpu / cpufreq / boost ................... 1
/ sys / device / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequenz-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Beobachteter CPU-Bereich "/ proc / cpuinfo" ... 1800 - 3700
Beobachteter "cpupower monitor" Frequenzbereich ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... Leistungsstufe 0

Mit anderen Worten, wenn Turbo Core im BIOS deaktiviert ist, wird es durch das Patching radeonnicht aktiviert.

Testfall 2.6: BIOS TC ein - CnQ aus / Linux n / a

UEFI BIOS Turbo Core Setting ............................ Aktiviert
UEFI BIOS Cool'n'Quiet-Einstellung .......................... Deaktiviert
/ sys / device / system / cpu / cpufreq / boost ................... n / a
/ sys / device / system / cpu / cpu * / cpufreq / scaling_governor ... n / a

"cpupower frequenz-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Beobachteter CPU-Bereich "/ proc / cpuinfo" ... 3700
Beobachteter "cpupower monitor" Frequenzbereich ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... Leistungsstufe 0

Laden | Kernfrequenzen
--------------- + -----------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4100 .. 4000
stress --cpu 3 | 3 x 4000 .. 3800
stress --cpu 4 | 4 x 3900 .. 3700

Wenn Cool'n'Qiet deaktiviert ist, bietet der Linux-Kernel keine Governor-Auswahl und geht (fälschlicherweise) davon aus, dass die Kerne mit einer festen Frequenz ausgeführt werden. Interessanterweise sind die resultierenden Turbo Core-Frequenzen die schlechteste aller getesteten Kombinationen in Testfallgruppe 2.

Zusammenfassung der Testfallgruppe 2

Mit dem gepatchten radeonTreiber funktioniert Turbo Core. Bisher wurden keine Instabilitäten (die der Grund sind, warum auch bapmbekannt als Turbo Core dort deaktiviert ist) festgestellt.

Testfallgruppe 3: Linux + fglrx (Katalysator)

Ich habe mit einer neuen Ubuntu-Installation (14.04 Server, Kernel 3.13) begonnen, die ich aufgrund des Vorhandenseins von acpi_cpufreq(Kernel-CPU-Skalierung) und radeon(Kernel-GPU-Treiber als vergleichbar mit Arch Linux (Installer 2014.08.01, Kernel 3.15.7) sehe ). Der Grund für den Wechsel zu Ubuntu ist die einfache Installation von fglrx. Ich habe den Stromverbrauch und das Verhalten bei der Neuinstallation überprüft, die verwendet wird radeon.

Ich habe fglrxüber die Befehlszeile ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) installiert und das System neu gestartet. Der Wechsel von radeonzu fglrxist sowohl hinsichtlich des Erscheinungsbilds der Konsole ( fglrx: 128 x 48 , radeon: viel höher) als auch des Stromverbrauchs im Leerlauf ( fglrx: 40 W , radeon: 30 W) sofort ersichtlich. Aber Turbo Core funktioniert sofort.

Testfall 3.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

UEFI BIOS Turbo Core Setting ............................ Aktiviert
UEFI BIOS Cool'n'Quiet-Einstellung .......................... Aktiviert
/ sys / device / system / cpu / cpufreq / boost ................... 1
/ sys / device / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequenz-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Beobachteter CPU-Bereich "/ proc / cpuinfo" ... 1800 - 3700
Beobachteter "cpupower monitor" Frequenzbereich ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... n / a

Laden | Kernfrequenzen
--------------- + ----------------------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 3900 (Kern chg)
stress --cpu 3 | 3 x 4100 .. 3700
stress --cpu 4 | 4 x 4000 .. 3600

Das fglrxVerhalten ist definitiv interessant. Wenn für einen der Testfälle in einer Testfallgruppe 'stress --cpu 2' aufgerufen wurde, befanden sich die beiden geladenen Kerne immer auf separaten Modulen. Bei fglrxkam es jedoch zu einer plötzlichen Neuzuweisung, sodass ein einzelnes Modul verwendet wurde (was ziemlich viel Strom spart, siehe unten). Nach einiger Zeit bewegte sich der geladene Kern zurück zum anderen Modul. Dies wurde nicht mit gesehen radeon. Könnte es sein, dass fglrxdie Kernaffinität von Prozessen manipuliert wird?

Zusammenfassung der Testfallgruppe 3

Der Vorteil von fglrxist, dass es Turbo Core sofort aktiviert, ohne dass es gepatcht werden muss.

Da fglrxin unserem Szenario 10 bis 12 W für die GPU auf einem Chip mit 65 W TDP verschwendet werden, sind die Gesamtergebnisse hinsichtlich der verfügbaren Kerngeschwindigkeiten nicht beeindruckend. Daher wurden keine weiteren Tests durchgeführt.

Auch aus technischer Sicht fglrxscheint das Verhalten von etwas traurig zu sein. Die Neuzuweisung eines von zwei ausgelasteten Kernen zum anderen Modul, um eine höhere Frequenz aufrechtzuerhalten, kann eine gute Idee sein oder auch nicht, da beide Kerne vor diesem Schritt einen eigenen L2-Cache hatten und anschließend einen gemeinsam nutzen müssen. Ob fglrxMetriken (wie Cache-Trefferfehler) zur Unterstützung der Entscheidung berücksichtigt werden, muss separat geklärt werden. Es gibt jedoch andere Berichte über das abrupte Verhalten .

Zusammenfassung des Stromverbrauchs

Einige der Delta-Werte in der folgenden Tabelle verschlechtern sich mit steigender Temperatur geringfügig. Man könnte sagen, dass sowohl der PWM-gesteuerte Lüfter als auch der Chip dort eine Rolle spielen.

System @State / -> Transition Delta | Verlustleistung des Systems
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86W
  @Bootloader | @ 108 .. 89W
  @Ubuntu Installer Idle | @ 40W
  @Linux Radeon Idle ondemand | @ 30W
  @Linux Radeon Leerlaufleistung | @ 30W
  @Linux fglrx Leerlauf ondemand | @ 40W
  1 Modul 1800 -> 3700 | + 13W
  1 Modul 1800 -> 4300 | + 25W
  1 Kern 1800 -> 3700 | + 5W
  1 Kern 1800 -> 4300 | + 10W
  "radeon" Video Out -> Deaktivieren | - 2W
  'fglrx "Video Out -> Darken | + - 0W
  @Linux Radeon Maximum | @ 103 .. 89W
  @Linux fglrx Maximum | @ 105 .. 92W

• Turbo Core scheint mehr zu bieten (zumindest bei Richland-APUs) als erwartet: Es gibt keinen merklichen Unterschied in der Verlustleistung, wenn der "On-Demand" -Skalierungsregler installiert ist, im Vergleich zu dem "Performance" -Regler. Althouth meldet /proc/cpuinfoimmer 37000 MHz unter dem Leistungsregler und cpupower monitorzeigt, dass die Kerne tatsächlich langsamer werden. In einigen Fällen wurden Frequenzen von nur 2000 MHz gezeigt; Es ist möglich, dass 1800 MHz auch intern verwendet werden.
• Der A10-6700 besteht aus zwei Modulen mit jeweils zwei Kernen. Wenn z. B. zwei Kerne inaktiv sind und zwei Kerne belegt sind und beschleunigt werden, ist das Systemverhalten unterschiedlich, je nachdem, ob sich die ausgelasteten Kerne auf demselben Modul befinden oder nicht.
  • Das Beschleunigen eines Moduls ist energieintensiver als das Beschleunigen eines Kerns.
  • Der L2-Cache wird pro Modul zugewiesen.
• Der Unterschied zwischen der Verlustleistung von zwei Kernen, die auf demselben Modul beschleunigen, und auf verschiedenen Modulen wurde durch Ersetzen stress --cpu 2(was immer zu einer Verteilung zwischen den beiden Modulen führte) durch bestimmt .taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• Der A10-6700 scheint eine Gesamtverlustgrenze für die APU zu haben (92 W zusammen mit den anderen Komponenten), wobei ein winziges Bit nur für die GPU reserviert ist (3 W). Mit radeonermöglicht es für kurze Zeit mehr und reduziert sich sehr reibungslos auf das Maximum, während mit fglrxbeobachtet wurde, dass diese Grenzen signifikanter überschritten werden und die Verlustleistung dann abrupt verringert wird.
• Während viele Leute behaupten, dass die Verzögerung der Kaveri-Verfügbarkeit von AMD beabsichtigt ist, weil sie ihre aktuellen APUs töten würde, bin ich anderer Meinung. Der Richland A10 hat ein ausgezeichnetes Power-Management bewiesen, und der Kaveri kann nicht mit seinem niedrigen Stromverbrauch im Leerlauf mithalten (Kaveris Chipkomplexität ist fast doppelt so hoch wie die von Richland, daher sind ein oder zwei weitere Entwicklungsschritte erforderlich).

Zusammenfassende Schlussfolgerung

• Das Einbeziehen der Temperatur in die Turbo Core-Logik (wie für den Schritt Trinity -> Richland angegeben) scheint sinnvoll zu sein und gut zu funktionieren, wie die Verringerung der Pwoer-Verlustleistung im BIOS und im Bootloader im Laufe der Zeit zeigt.
• Für das Cosole / Server-Szenario unterstützt der A10-6700 langfristig 4 Kerne bei 3700 MHz (3800 MHz mit Turbo Core), zumindest mit dem radeonTreiber. Es gibt wahrscheinlich nicht viele Chancen, dieses Leistungsniveau beizubehalten, wenn die GPU etwas Arbeit zu erledigen hat.
• Es scheint, dass die 65-W-TDP unter Volllast dauerhaft leicht überschritten werden kann, aber es ist schwer zu sagen, da das Netzteil bei 30 W einen geringeren Wirkungsgrad aufweist. Da es klare Anzeichen dafür gibt, dass die Temperatur berücksichtigt wird (eine Spitzenverlustleistung von fast 110 W wurde beobachtet, bevor sie auf 90 W reduziert wurde, und es wurden auch 2 Kerne bei 4300 MHz für einige Zeit gemeldet), kann eine Investition in die APU-Kühlung eine sein gute Idee. Mainboards, die auf 65 W TDP beschränkt sind, können jedoch nur so viel Strom liefern, dass die APU definitiv eine harte Grenze auferlegt.
• Wenn Sie beabsichtigen, eine Richland-APU für Computer unter Linux zu verwenden, möchten Sie auf jeden Fall einen gepatchten radeonTreiber verwenden (wenn Sie nicht auf Instabilitäten stoßen - insbesondere in Verbindung mit der Aktivierung von Dynamic Power Management). Andernfalls erhalten Sie nicht den vollen Wert.
• Seltsamerweise scheint es das beste Setup zu sein, sowohl Turbo Core als auch Cool'n'Quiet im BIOS zu aktivieren, dann aber den performanceSkalierungsregler zu wählen - zumindest, wenn sich Ihre APU wie die hier getestete verhält. Sie haben den gleichen Stromverbrauch wie bei einer ondemandschnelleren Frequenzskalierung und weniger Kernel-Overhead, um die Skalierungsentscheidung zu treffen.

Danksagung

Ein besonderer Dank geht an Alex Deucher, der mich bei bugzilla.kernel.org deutlich in die richtige Richtung getrieben hat .

Ich bin beeindruckt von der Qualität des kostenlosen radeonTreibers und möchte dem gesamten Team für die Wartung dieser Software danken, die sorgfältig ausgearbeitet zu sein scheint. Wenn radeonich mich nicht so verhalten würde, wäre meine Entscheidung für den A10-6700 im Wesentlichen falsch gewesen.