AMD A10-6700（リッチランド）APU体験

Question

[編集：プロセッサの選択に関する結論]

AMD対AMD：
- RichlandはTrinityよりもこれをうまく行います。
- KaveriはRichlandのアイドルモード消費電力と競合することはできません（少なくともまだ）。
- A10-6700のGPUは過大評価されたかもしれないが、あまり活用度がないようで、ちょっと残念だ。一部のアルゴリズムはコンピューティングパフォーマンスを展開できます。しかし、これがプロセッサの消費電力にどのような影響を与えるかはわかりません。
- A10-6790KとA10-6700は同じプロセッサであるようですが、Turbo Coreアクセラレーションのパラメータ設定は異なります。これが本当であれば、A10-6790Kはより高いTDPのためにより長く昇圧したり、長期的に高い周波数を提供することができます。ただし、別のCPUファンが必要です（スペースと温度/寿命に関する考慮事項）。
AMD A10-6700対Intel Core i3-3220：
- A10-6700にはより多くのGPU性能があり、ここでは使用されていません。
- i3-3220はアイドルモードの消費電力が低くなります。
- i3-3220は一般的なベンチマークでより速く計算されますが、2つのハイパースレッドコアがどのように4つのすべての機能を備えたコアのように動作できるかはわかりません（少なくとも深刻なキャッシュを想定している場合）。しかし、確かなベンチマークは見つからず、ほんの数兆候しか見つかりませんでした。

[編集：Linux 3.16以降、無料のRadeonドライバのパラメータはbapmKaveri、Kabini、およびデスクトップTrinity、Richlandシステムに対してデフォルトで設定されています。]

ただし、3.16ベースのDebianでは起動パラメータが機能しますが、デフォルトは（まだ？）機能しないようです。バラより最大のエネルギー効率とコンピューティング効率のためにAMD Turbo Core APUを搭載したDebianシステム（2D中心またはコンソール/サーバー）を設定するには？

[編集：無料のRadeonドライバにはすぐにbapmパラメータがある予定です。]

結論は、radeonAPUの無料ドライバのパッチバージョンを使用してTurbo Coreをサポートし、可能であればそれを最大限に活用することです（3Dグラフィックスを除く）ので（有効にするとbapm一部の構成で不安定になる可能性があります）、これが推奨されます。ニュースRadeonの将来のバージョンには、Bapmを有効にするパラメータがあります。。

[下のオリジナル記事]

AMD A10-6700（リッチランド）APU体験

プロセッサの選択

私の最初のPCは、Slackwareソースコードパッケージを含む数十の3.5インチフロッピーディスクで構成された486DX2-66でした。現在、多くのことが変わり、現在多くの業界では依然として製品バリアントの数を増やす段階にあるようです。

このような状況とAMDの最近の不幸な決定は、ミニサーバープラットフォームの決定を容易にしませんでした。しかし、最終的にはA10-6700が良い選択になると思います。

いくつかのレビューでは、Kaveri（まだ広く利用できない）がRichlandやTrinityよりもアイドルモードでより多くの電力を消費すると提案しています。
Trinity A10-5700と比較して、Richland A10-6700の利点は明らかです。最小周波数が低く、最大周波数が高く、ターボコアがより細かくなりました（温度を考慮してください - GPUがアイドル状態のときにかなりの量です）。利点）
A10-6700のGPUは価格が高すぎるという（マーケティング中心のネーミング）、APUはかなり価格が高いようです。

その他のコンポーネントと設定

選択できるプロセッサは数多くありますが、利用可能なMini-ITXマザーボードはほとんどありません。 ASRock FM2A78M-ITX+は合理的な選択肢のようです。テストはファームウェアV1.30を使用して行われました（作成時点ではアップデートは提供されません）。

電源装置の公称出力の80％しか消費しません。一方、多くのデバイスは50％未満でロードすると効率的に動作しません。予想電力消費量が35W〜120Wのシステム用のエネルギー効率の高い電源装置を見つけることは困難です。私はHaiyun G360 80+ Goldを使ってこれらのテストを行いました。なぜなら、この製品は低負荷効率の点でほとんどの競合他社よりも優れていたからです。

テスト設定には、2 つの 8 GB DDR3-1866 RAM (このように構成され、1333 と比較して違いがあります)、SSD ドライブ、PWM 制御大容量 CPU ファンも含まれていました。

正確な測定を行うことが報告されたAVM Fritz!DECT 200を使用して測定を行いました。しかし、その妥当性は名前もない古い装置を用いて検証された。不一致が見つかりませんでした。測定されたシステム消費電力には、低負荷による電源装置の効率の低下が含まれます。

[W] QHD画面をHDMIに接続してください。

UEFI BIOSでは、GPUの初期共有メモリ設定は32Mです。また、オンボードGPUがデフォルトで選択され、IOMMUが有効になります。

X またはその他のグラフィックシステムがインストールまたは構成されていません。ビデオ出力はコンソールモードに制限されます。

基本的な

知っておくべきことがいくつかあります。

Cool'n'Quietの決定はプロセッサ外部ソフトウェアによって行われ、Turbo Coreの決定はAPU（またはCPU）の追加のマイクロコントローラによって自律的に行われます。
多くのツールや/proc場所は/sysTurbo Coreの活動を報告しません。cpufreq-aperf、cpupower frequency-info実行しますcpupower monitorがmodprobe msr。

テストケースグループ1：Linux + radeon

新しいArch Linux（インストールプログラム2014.08.01、カーネル3.15.7）で起動します。ここで重要な要素は、acpi_cpufreq（カーネルCPU拡張）と（カーネルGPUドライバ）の存在radeonとそれをパッチする簡単な方法ですradeon。

テストケース1.1：BIOS TC On - CnQ On / Linux OnDemand - Boost

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
---------------+---
圧力 - CPU 1×3700 |
圧力--cpu 2 |
圧力--CPU 3×3700 |
圧力--CPU 4×3700 |

テストケース1.2：BIOS TCの有効化 - CnQの有効化/ Linuxのパフォーマンス - 改善

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... パフォーマンス

「cpu電力周波数情報」
観測された '/proc/cpuinfo' CPU MHz 範囲... 3700
観察された「cpupowerモニター」周波数範囲... 2000 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
---------------+---
圧力 - CPU 1×3700 |
圧力--cpu 2 |
圧力--CPU 3×3700 |
圧力--CPU 4×3700 |

テストケースグループ1の概要

この場合、Turbo Coreベースの強化は不可能です。radeonこのフラグは、現在の場合、安定性の問題のためドライバによって無効になっています。bapm。したがって、追加のテストはスキップされました。

テストケースグループ2：Bapmパッチを含むLinux + radeon

を有効にするには、bapm新しいArch Linux（インストールプログラム2014.08.01、カーネル3.15.7）で起動し（3.15.8）core linuxでパッケージをインポートして使用するように編集し、次のようにソースをインポートして変更し、次にコンパイルしました。。その後、インストールして更新しました（もちろんYMMV）。ABSPKGBUILDpkgbase=linux-tcmakepkg --nobuildpi->enable_bapm = true;trinity_dpm_init()src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.cmakepkg --noextractpacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzpacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xzGRUBgrub-mkconfig -o /boot/grub/grub.cfg

その結果、私はbootを選択したか、linux次のlinux-tcテストでは後者を参照しました。

テストケース2.1：BIOS TC On - CnQ On / Linux OnDemand - Boost

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
-------------+----
圧力 - CPU 1×4300 |
圧力--cpu 2 | 2×4200..4100
圧力 - CPU 3 | 3×4100..3900
圧力 - CPU 4 | 4×4000..3800

テストケース2.2：BIOS TC On - CnQ On / Linuxパフォーマンス - 改善

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... パフォーマンス

「cpu電力周波数情報」
観測された '/proc/cpuinfo' CPU MHz 範囲... 3700
観察された「cpupowerモニター」周波数範囲... 2000 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
-------------+----
圧力 - CPU 1×4300 |
圧力--cpu 2 | 2×4200..4100
圧力 - CPU 3 | 3×4100..3900
圧力 - CPU 4 | 4×4000..3800

テストケース 2.3: BIOS TC On - CnQ On/Linux OnDemand - ブーストなし

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost........... 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 1

読み込み中|
---------------+---
圧力 - CPU 1×3700 |
圧力--cpu 2 |
圧力--CPU 3×3700 |
圧力--CPU 4×3700 |

テストケース2.4：BIOS TC On - CnQ On / Linuxパフォーマンス - 改善なし

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost........... 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... パフォーマンス

「cpu電力周波数情報」
観測された '/proc/cpuinfo' CPU MHz 範囲... 3700
観察された「cpupowerモニター」周波数範囲... 2000 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 1

読み込み中|
---------------+---
圧力 - CPU 1×3700 |
圧力--cpu 2 |
圧力--CPU 3×3700 |
圧力--CPU 4×3700 |

テストケース 2.5: BIOS TC オフ - CnQ オン/Linux OnDemand - ブースト

UEFI BIOSターボコアの設定............................................. ........ ... ...障害がある
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

つまり、BIOSでTurbo Coreが無効になっていると、パッチはradeonそれを有効にしません。

テストケース2.6：BIOS TCをオンにする - CnQをオフにする/ Linux該当なし

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定.................................無効
/sys/devices/system/cpu/cpufreq/boost...........該当なし
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 該当なし

「cpu電力周波数情報」
観測された '/proc/cpuinfo' CPU MHz 範囲... 3700
観察された「cpupowerモニター」周波数範囲... 2000 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
-------------+----
圧力 - CPU 1×4300 |
圧力 - CPU 2 | 2×4100..4000
圧力 - CPU 3 | 3×4000..3800
圧力 - CPU 4 | 4×3900..3700

Cool'n'Qietが無効になっている場合、Linuxカーネルはコーディネータの選択を提供せず、カーネルが固定頻度で実行されていると誤って仮定します。興味深いことに、生成されたターボコア周波数は、テストケースグループ2のすべてのテスト組み合わせの中で最も悪いです。

テストケースグループ2のまとめ

パッチ付きradeonドライバを使用すると、Turbo Coreが機能します。bapmこれまで不安定性は見つかりませんでした（これがターボコアが無効になった理由です）。

テストケースグループ3：Linux + fglrx（Catalyst）

acpi_cpufreq私は（カーネルCPU拡張）とradeon（カーネルGPUドライバ）の存在により、Arch Linux（インストールプログラム2014.08.01、カーネル3.15.7）に似ていると仮定する新しいUbuntu（14.04サーバー、カーネル3.13）のインストールから始めました。 Ubuntuに切り替えた理由はインストールが簡単だからですfglrx。 radeon.

fglrxコマンドライン（sudo apt-get install linux-headers-generic、、）からインストールsudo apt-get install fglrxし、システムを再起動しました。コンソールの外観（：128 x 48、：より高い）とアイドルモードの消費電力（：40W、：30W）の観点radeonからの変更点がfglrx目立つ。しかし、Turbo Coreはすぐに機能します。fglrxradeonfglrxradeon

テストケース3.1：BIOS TC On - CnQ On / Linux OnDemand - Boost

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... 該当なし

読み込み中|
---------------+---------------
圧力 - CPU 1×4300 |
ストレス - CPU 2 | 2 x 4200 .. 3900(コア変更)
圧力 - CPU 3 | 3×4100..3700
圧力 - CPU 4 | 4×4000..3600

このfglrx行動は確かに興味深いです。テストケースグループのテストケースで「stress --cpu 2」が呼び出されると、ロードされた2つのコアは常に別々のモジュールにあります。ただし、使用するとfglrx突然再割り当てが発生し、単一のモジュールが使用されます（これにより大幅な電力が節約されます。以下を参照）。一定時間が経過すると、ロードされたコアは別のモジュールに戻ります。これは見えませんradeon。fglrxプロセスの重要な親和性を操作することは可能ですか？

テストケースグループ3の概要

利点fglrxは、パッチなしですぐにTurbo Coreを使用できることです。

fglrx私たちのシナリオでは、TDPが65WのチップでGPUが10〜12Wの電力を無駄にするので、利用可能なコア速度に関する全体的な結果は印象的ではありません。したがって、これ以上のテストは行われなかった。

また、エンジニアリングの観点から見ると、これらの動作はfglrx少し気をつけています。周波数を高く保つために、2つの使用されているコアのうちの1つを別のモジュールに再割り当てすることは良い考えかもしれません。これは、このステップの前に両方のコアに独自のL2キャッシュがあり、その後1つを共有する必要があるためです。ただし、fglrx決定を裏付けると見なされる指標（たとえば、キャッシュヒット失敗）は別々に指定する必要があります。突然の行動についての他の報告もありました。

消費電力のまとめ

下表の一部のデルタ値は、温度が上昇するにつれてやや悪くなります。 PWM制御ファンとチップの両方がそこで動作すると主張することができます。

System@State/->変換増加|システム電力消費
---------+--------------- --- ----------
  @BIOS | @95..86W
  ブートローダー
  @ Ubuntuインストーラアイドル@ 40W |
  @ Linux Radeonアイドルオンデマンド@ 30W |
  @ Linux Radeonアイドルパフォーマンス@ 30W |
  @Linux fglrxアイドルオンデマンド@ 40W |
  1モジュール1800 -> 3700 |
  1モジュール1800 - > 4300 |
  1コア1800 - > 3700 |
  1コア1800 - > 4300 |
  "radeon"ビデオ出力 - >無効 - 2W |
  'fglrx'ビデオ出力 - >ダーク| +- 0W
  @ Linux Radeon Max @ 103..89W |
  @Linux fglrx 最大 @105..92W |

Turbo Coreは(少なくともRichland APUの場合)予想以上に多くの機能を実行しているようです. 「Performance」ガバナーを使用することと「On Demand」スケーリング・ガバナーを使用する場合、消費電力に顕著な違いはありません。/proc/cpuinfoパフォーマンスガバナーでは常に37000MHzが報告されていますが、これはcpupower monitor実際にコアが遅くなっていることを示しています。場合によっては、2000MHzほど低い周波数が表示され、1800MHzも内部で使用できます。
A10-6700は、それぞれ2つのコアを持つ2つのモジュールで構成されています。たとえば、2つのコアがアイドル状態で、2つのコアが使用中でスピードが速い場合、使用しているコアが同じモジュールにあるかどうかによってシステムの動作が異なります。
- 加速モジュールは、加速コアよりも多くのエネルギーを消費します。
- L2キャッシュはモジュールごとに割り当てられます。
同じモジュールで加速された2つのコアの消費電力と、異なるモジュールで加速された2つのコアの消費電力の差は、置き換えstress --cpu 2によって決まります（常に2つのモジュール間で分配が発生します）。taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
A10-6700は、APUの総消費電力制限（他のコンポーネントと一緒に92W）があるように見え、GPUには小さな部分（3W）しか残りません。使用中はradeon短時間でより多くを許可し、非常にスムーズに最大値まで減少しますが、使用中はこれらの制限をはるかに超えてから、fglrx消費電力が突然減少することを観察できます。
多くの人がKaveriの可用性を遅らせることは現在APUを台無しにするので、AMD側で意図的なものであると主張していますが、私は違うと思います。 Richland A10はすでに優れた電力管理を示しており、Kaveriは低アイドル状態の電力消費と競合することはできません（KaveriのチップはRichlandのチップよりもほぼ2倍複雑であるため、1つまたは2つの開発ステップが必要です）。

包括的な結論

Turbo Coreロジック（Trinity - > Richlandフェーズで報告されているように）に温度を含めることは合理的でうまく機能するようです。 BIOSとブートローダで時間が経つにつれて消費電力が減少するのを見るとわかります。
radeonコンソール/サーバーシナリオの場合、A10-6700は少なくともドライバ側で3700MHz（ターボコアの場合3800MHz）で4つのコアを長期的にサポートします。 GPUがいくつかのタスクを実行する必要がある場合は、このレベルのパフォーマンスを維持する機会が少なくなる可能性があります。
最大負荷で65W TDPを永久にわずかに超えることが可能であるように思われますが、30Wでは電源の効率が低下するため、話すことは困難です。温度が考慮されるという明白な兆候があるため（90Wに低下し始める前にほぼ110Wの最大消費電力が観察され、しばらく4300MHzの2つのコアが報告されている）、APU冷却に投資するのは賢明な選択肢かもしれません。良いアイデア。しかし、TDP制限が65Wのマザーボードはそれだけの電流しか伝達できないため、APUは明らかに制限されます。
LinuxでコンピューティングにRichland APUを使用する予定の場合は、パッチ付きドライバを使用する必要がありますradeon（不安定な問題が発生しない場合、特に動的電源管理が有効になっている場合）。そうでなければ、全体的な価値を得ることはできません。
奇妙なことに、最高の設定はBIOSでTurbo CoreとCool'n'Quietを有効にしてからスケーリングperformanceガバナーを選択することです。少なくともAPUがここでテストしたのと同様に動作する場合です。ondemandスケーリング決定を行うときの消費電力は同じですが、周波数スケーリングが速く、コアのオーバーヘッドが少なくなります。

感謝の言葉

Alex Deucherに特別な感謝を申し上げます。私を正しい方向に案内しました。 bugzilla.kernel.org。

私は無料のドライバーの品質に本当に感銘を受けましたradeon。そうradeonでなければ、A10-6700を選んだ私の決定は大きな間違いでした。

Answer 1

[編集：プロセッサの選択に関する結論]

AMD対AMD：
- RichlandはTrinityよりもこれをうまく行います。
- KaveriはRichlandのアイドルモード消費電力と競合することはできません（少なくともまだ）。
- A10-6700のGPUは過大評価されたかもしれないが、あまり活用度がないようで、ちょっと残念だ。一部のアルゴリズムはコンピューティングパフォーマンスを展開できます。しかし、これがプロセッサの消費電力にどのような影響を与えるかはわかりません。
- A10-6790KとA10-6700は同じプロセッサであるようですが、Turbo Coreアクセラレーションのパラメータ設定は異なります。これが本当であれば、A10-6790Kはより高いTDPのためにより長く昇圧したり、長期的に高い周波数を提供することができます。ただし、別のCPUファンが必要です（スペースと温度/寿命に関する考慮事項）。
AMD A10-6700対Intel Core i3-3220：
- A10-6700にはより多くのGPU性能があり、ここでは使用されていません。
- i3-3220はアイドルモードの消費電力が低くなります。
- i3-3220は一般的なベンチマークでより速く計算されますが、2つのハイパースレッドコアがどのように4つのすべての機能を備えたコアのように動作できるかはわかりません（少なくとも深刻なキャッシュを想定している場合）。しかし、確かなベンチマークは見つからず、ほんの数兆候しか見つかりませんでした。

[編集：Linux 3.16以降、無料のRadeonドライバのパラメータはbapmKaveri、Kabini、およびデスクトップTrinity、Richlandシステムに対してデフォルトで設定されています。]

バラより[フル]radeon drm-fixes-3.16。

ただし、3.16ベースのDebianでは起動パラメータが機能しますが、デフォルトは（まだ？）機能しないようです。バラより最大のエネルギー効率とコンピューティング効率のためにAMD Turbo Core APUを搭載したDebianシステム（2D中心またはコンソール/サーバー）を設定するには？

[編集：無料のRadeonドライバにはすぐにbapmパラメータがある予定です。]

結論は、radeonAPUの無料ドライバのパッチバージョンを使用してTurbo Coreをサポートし、可能であればそれを最大限に活用することです（3Dグラフィックスを除く）ので（有効にするとbapm一部の構成で不安定になる可能性があります）、これが推奨されます。ニュースRadeonの将来のバージョンには、Bapmを有効にするパラメータがあります。。

[下のオリジナル記事]

AMD A10-6700（リッチランド）APU体験

プロセッサの選択

私の最初のPCは、Slackwareソースコードパッケージを含む数十の3.5インチフロッピーディスクで構成された486DX2-66でした。現在、多くのことが変わり、現在多くの業界では依然として製品バリアントの数を増やす段階にあるようです。

このような状況とAMDの最近の不幸な決定は、ミニサーバープラットフォームの決定を容易にしませんでした。しかし、最終的にはA10-6700が良い選択になると思います。

いくつかのレビューでは、Kaveri（まだ広く利用できない）がRichlandやTrinityよりもアイドルモードでより多くの電力を消費すると提案しています。
Trinity A10-5700と比較して、Richland A10-6700の利点は明らかです。最小周波数が低く、最大周波数が高く、ターボコアがより細かくなりました（温度を考慮してください - GPUがアイドル状態のときにかなりの量です）。利点）
A10-6700のGPUは価格が高すぎるという（マーケティング中心のネーミング）、APUはかなり価格が高いようです。

その他のコンポーネントと設定

選択できるプロセッサは数多くありますが、利用可能なMini-ITXマザーボードはほとんどありません。 ASRock FM2A78M-ITX+は合理的な選択肢のようです。テストはファームウェアV1.30を使用して行われました（作成時点ではアップデートは提供されません）。

電源装置の公称出力の80％しか消費しません。一方、多くのデバイスは50％未満でロードすると効率的に動作しません。予想電力消費量が35W〜120Wのシステム用のエネルギー効率の高い電源装置を見つけることは困難です。私はHaiyun G360 80+ Goldを使ってこれらのテストを行いました。なぜなら、この製品は低負荷効率の点でほとんどの競合他社よりも優れていたからです。

テスト設定には、2 つの 8 GB DDR3-1866 RAM (このように構成され、1333 と比較して違いがあります)、SSD ドライブ、PWM 制御大容量 CPU ファンも含まれていました。

正確な測定を行うことが報告されたAVM Fritz!DECT 200を使用して測定を行いました。しかし、その妥当性は名前もない古い装置を用いて検証された。不一致が見つかりませんでした。測定されたシステム消費電力には、低負荷による電源装置の効率の低下が含まれます。

[W] QHD画面をHDMIに接続してください。

UEFI BIOSでは、GPUの初期共有メモリ設定は32Mです。また、オンボードGPUがデフォルトで選択され、IOMMUが有効になります。

X またはその他のグラフィックシステムがインストールまたは構成されていません。ビデオ出力はコンソールモードに制限されます。

基本的な

知っておくべきことがいくつかあります。

Cool'n'Quietの決定はプロセッサ外部ソフトウェアによって行われ、Turbo Coreの決定はAPU（またはCPU）の追加のマイクロコントローラによって自律的に行われます。
多くのツールや/proc場所は/sysTurbo Coreの活動を報告しません。cpufreq-aperf、cpupower frequency-info実行しますcpupower monitorがmodprobe msr。

テストケースグループ1：Linux + radeon

新しいArch Linux（インストールプログラム2014.08.01、カーネル3.15.7）で起動します。ここで重要な要素は、acpi_cpufreq（カーネルCPU拡張）と（カーネルGPUドライバ）の存在radeonとそれをパッチする簡単な方法ですradeon。

テストケース1.1：BIOS TC On - CnQ On / Linux OnDemand - Boost

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
---------------+---
圧力 - CPU 1×3700 |
圧力--cpu 2 |
圧力--CPU 3×3700 |
圧力--CPU 4×3700 |

テストケース1.2：BIOS TCの有効化 - CnQの有効化/ Linuxのパフォーマンス - 改善

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... パフォーマンス

「cpu電力周波数情報」
観測された '/proc/cpuinfo' CPU MHz 範囲... 3700
観察された「cpupowerモニター」周波数範囲... 2000 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
---------------+---
圧力 - CPU 1×3700 |
圧力--cpu 2 |
圧力--CPU 3×3700 |
圧力--CPU 4×3700 |

テストケースグループ1の概要

この場合、Turbo Coreベースの強化は不可能です。radeonこのフラグは、現在の場合、安定性の問題のためドライバによって無効になっています。bapm。したがって、追加のテストはスキップされました。

テストケースグループ2：Bapmパッチを含むLinux + radeon

を有効にするには、bapm新しいArch Linux（インストールプログラム2014.08.01、カーネル3.15.7）で起動し（3.15.8）core linuxでパッケージをインポートして使用するように編集し、次のようにソースをインポートして変更し、次にコンパイルしました。。その後、インストールして更新しました（もちろんYMMV）。ABSPKGBUILDpkgbase=linux-tcmakepkg --nobuildpi->enable_bapm = true;trinity_dpm_init()src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.cmakepkg --noextractpacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzpacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xzGRUBgrub-mkconfig -o /boot/grub/grub.cfg

その結果、私はbootを選択したか、linux次のlinux-tcテストでは後者を参照しました。

テストケース2.1：BIOS TC On - CnQ On / Linux OnDemand - Boost

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
-------------+----
圧力 - CPU 1×4300 |
圧力--cpu 2 | 2×4200..4100
圧力 - CPU 3 | 3×4100..3900
圧力 - CPU 4 | 4×4000..3800

テストケース2.2：BIOS TC On - CnQ On / Linuxパフォーマンス - 改善

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... パフォーマンス

「cpu電力周波数情報」
観測された '/proc/cpuinfo' CPU MHz 範囲... 3700
観察された「cpupowerモニター」周波数範囲... 2000 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
-------------+----
圧力 - CPU 1×4300 |
圧力--cpu 2 | 2×4200..4100
圧力 - CPU 3 | 3×4100..3900
圧力 - CPU 4 | 4×4000..3800

テストケース 2.3: BIOS TC On - CnQ On/Linux OnDemand - ブーストなし

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost........... 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 1

読み込み中|
---------------+---
圧力 - CPU 1×3700 |
圧力--cpu 2 |
圧力--CPU 3×3700 |
圧力--CPU 4×3700 |

テストケース2.4：BIOS TC On - CnQ On / Linuxパフォーマンス - 改善なし

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost........... 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... パフォーマンス

「cpu電力周波数情報」
観測された '/proc/cpuinfo' CPU MHz 範囲... 3700
観察された「cpupowerモニター」周波数範囲... 2000 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 1

読み込み中|
---------------+---
圧力 - CPU 1×3700 |
圧力--cpu 2 |
圧力--CPU 3×3700 |
圧力--CPU 4×3700 |

テストケース 2.5: BIOS TC オフ - CnQ オン/Linux OnDemand - ブースト

UEFI BIOSターボコアの設定............................................. ........ ... ...障害がある
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 3700
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

つまり、BIOSでTurbo Coreが無効になっていると、パッチはradeonそれを有効にしません。

テストケース2.6：BIOS TCをオンにする - CnQをオフにする/ Linux該当なし

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定.................................無効
/sys/devices/system/cpu/cpufreq/boost...........該当なし
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 該当なし

「cpu電力周波数情報」
観測された '/proc/cpuinfo' CPU MHz 範囲... 3700
観察された「cpupowerモニター」周波数範囲... 2000 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... 電源レベル 0

読み込み中|
-------------+----
圧力 - CPU 1×4300 |
圧力 - CPU 2 | 2×4100..4000
圧力 - CPU 3 | 3×4000..3800
圧力 - CPU 4 | 4×3900..3700

Cool'n'Qietが無効になっている場合、Linuxカーネルはコーディネータの選択を提供せず、カーネルが固定頻度で実行されていると誤って仮定します。興味深いことに、生成されたターボコア周波数は、テストケースグループ2のすべてのテスト組み合わせの中で最も悪いです。

テストケースグループ2のまとめ

パッチ付きradeonドライバを使用すると、Turbo Coreが機能します。bapmこれまで不安定性は見つかりませんでした（これがターボコアが無効になった理由です）。

テストケースグループ3：Linux + fglrx（Catalyst）

acpi_cpufreq私は（カーネルCPU拡張）とradeon（カーネルGPUドライバ）の存在により、Arch Linux（インストールプログラム2014.08.01、カーネル3.15.7）に似ていると仮定する新しいUbuntu（14.04サーバー、カーネル3.13）のインストールから始めました。 Ubuntuに切り替えた理由はインストールが簡単だからですfglrx。 radeon.

fglrxコマンドライン（sudo apt-get install linux-headers-generic、、）からインストールsudo apt-get install fglrxし、システムを再起動しました。コンソールの外観（：128 x 48、：より高い）とアイドルモードの消費電力（：40W、：30W）の観点radeonからの変更点がfglrx目立つ。しかし、Turbo Coreはすぐに機能します。fglrxradeonfglrxradeon

テストケース3.1：BIOS TC On - CnQ On / Linux OnDemand - Boost

UEFI BIOSターボコアの設定............................................. ...有効化
UEFI BIOS Cool'n'Quietの設定........................................有効
/sys/devices/system/cpu/cpufreq/boost.............. 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... リクエスト時に

「cpu電力周波数情報」
観察された「/proc/cpuinfo」CPU MHz範囲... 1800 - 3700
観察された「cpupowerモニター」周波数範囲... 1800 - 4300
/sys/kernel/debug/dri/0/radeon_pm_info... 該当なし

読み込み中|
---------------+---------------
圧力 - CPU 1×4300 |
ストレス - CPU 2 | 2 x 4200 .. 3900(コア変更)
圧力 - CPU 3 | 3×4100..3700
圧力 - CPU 4 | 4×4000..3600

このfglrx行動は確かに興味深いです。テストケースグループのテストケースで「stress --cpu 2」が呼び出されると、ロードされた2つのコアは常に別々のモジュールにあります。ただし、使用するとfglrx突然再割り当てが発生し、単一のモジュールが使用されます（これにより大幅な電力が節約されます。以下を参照）。一定時間が経過すると、ロードされたコアは別のモジュールに戻ります。これは見えませんradeon。fglrxプロセスの重要な親和性を操作することは可能ですか？

テストケースグループ3の概要

利点fglrxは、パッチなしですぐにTurbo Coreを使用できることです。

fglrx私たちのシナリオでは、TDPが65WのチップでGPUが10〜12Wの電力を無駄にするので、利用可能なコア速度に関する全体的な結果は印象的ではありません。したがって、これ以上のテストは行われなかった。

また、エンジニアリングの観点から見ると、これらの動作はfglrx少し気をつけています。周波数を高く保つために、2つの使用されているコアのうちの1つを別のモジュールに再割り当てすることは良い考えかもしれません。これは、このステップの前に両方のコアに独自のL2キャッシュがあり、その後1つを共有する必要があるためです。ただし、fglrx決定を裏付けると見なされる指標（たとえば、キャッシュヒット失敗）は別々に指定する必要があります。突然の行動についての他の報告もありました。

消費電力のまとめ

下表の一部のデルタ値は、温度が上昇するにつれてやや悪くなります。 PWM制御ファンとチップの両方がそこで動作すると主張することができます。

System@State/->変換増加|システム電力消費
---------+--------------- --- ----------
  @BIOS | @95..86W
  ブートローダー
  @ Ubuntuインストーラアイドル@ 40W |
  @ Linux Radeonアイドルオンデマンド@ 30W |
  @ Linux Radeonアイドルパフォーマンス@ 30W |
  @Linux fglrxアイドルオンデマンド@ 40W |
  1モジュール1800 -> 3700 |
  1モジュール1800 - > 4300 |
  1コア1800 - > 3700 |
  1コア1800 - > 4300 |
  "radeon"ビデオ出力 - >無効 - 2W |
  'fglrx'ビデオ出力 - >ダーク| +- 0W
  @ Linux Radeon Max @ 103..89W |
  @Linux fglrx 最大 @105..92W |

Turbo Coreは(少なくともRichland APUの場合)予想以上に多くの機能を実行しているようです. 「Performance」ガバナーを使用することと「On Demand」スケーリング・ガバナーを使用する場合、消費電力に顕著な違いはありません。/proc/cpuinfoパフォーマンスガバナーでは常に37000MHzが報告されていますが、これはcpupower monitor実際にコアが遅くなっていることを示しています。場合によっては、2000MHzほど低い周波数が表示され、1800MHzも内部で使用できます。
A10-6700は、それぞれ2つのコアを持つ2つのモジュールで構成されています。たとえば、2つのコアがアイドル状態で、2つのコアが使用中でスピードが速い場合、使用しているコアが同じモジュールにあるかどうかによってシステムの動作が異なります。
- 加速モジュールは、加速コアよりも多くのエネルギーを消費します。
- L2キャッシュはモジュールごとに割り当てられます。
同じモジュールで加速された2つのコアの消費電力と、異なるモジュールで加速された2つのコアの消費電力の差は、置き換えstress --cpu 2によって決まります（常に2つのモジュール間で分配が発生します）。taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
A10-6700は、APUの総消費電力制限（他のコンポーネントと一緒に92W）があるように見え、GPUには小さな部分（3W）しか残りません。使用中はradeon短時間でより多くを許可し、非常にスムーズに最大値まで減少しますが、使用中はこれらの制限をはるかに超えてから、fglrx消費電力が突然減少することを観察できます。
多くの人がKaveriの可用性を遅らせることは現在APUを台無しにするので、AMD側で意図的なものであると主張していますが、私は違うと思います。 Richland A10はすでに優れた電力管理を示しており、Kaveriは低アイドル状態の電力消費と競合することはできません（KaveriのチップはRichlandのチップよりもほぼ2倍複雑であるため、1つまたは2つの開発ステップが必要です）。

包括的な結論

Turbo Coreロジック（Trinity - > Richlandフェーズで報告されているように）に温度を含めることは合理的でうまく機能するようです。 BIOSとブートローダで時間が経つにつれて消費電力が減少するのを見るとわかります。
radeonコンソール/サーバーシナリオの場合、A10-6700は少なくともドライバ側で3700MHz（ターボコアの場合3800MHz）で4つのコアを長期的にサポートします。 GPUがいくつかのタスクを実行する必要がある場合は、このレベルのパフォーマンスを維持する機会が少なくなる可能性があります。
最大負荷で65W TDPを永久にわずかに超えることが可能であるように思われますが、30Wでは電源の効率が低下するため、話すことは困難です。温度が考慮されるという明白な兆候があるため（90Wに低下し始める前にほぼ110Wの最大消費電力が観察され、しばらく4300MHzの2つのコアが報告されている）、APU冷却に投資するのは賢明な選択肢かもしれません。良いアイデア。しかし、TDP制限が65Wのマザーボードはそれだけの電流しか伝達できないため、APUは明らかに制限されます。
LinuxでコンピューティングにRichland APUを使用する予定の場合は、パッチ付きドライバを使用する必要がありますradeon（不安定な問題が発生しない場合、特に動的電源管理が有効になっている場合）。そうでなければ、全体的な価値を得ることはできません。
奇妙なことに、最高の設定はBIOSでTurbo CoreとCool'n'Quietを有効にしてからスケーリングperformanceガバナーを選択することです。少なくともAPUがここでテストしたのと同様に動作する場合です。ondemandスケーリング決定を行うときの消費電力は同じですが、周波数スケーリングが速く、コアのオーバーヘッドが少なくなります。

感謝の言葉

Alex Deucherに特別な感謝を申し上げます。私を正しい方向に案内しました。 bugzilla.kernel.org。

私は無料のドライバーの品質に本当に感銘を受けましたradeon。そうradeonでなければ、A10-6700を選んだ私の決定は大きな間違いでした。

AMD A10-6700（リッチランド）APU体験

ベストアンサー1

AMD A10-6700（リッチランド）APU体験

プロセッサの選択

その他のコンポーネントと設定

基本的な

テストケースグループ1：Linux + radeon

テストケース1.1：BIOS TC On - CnQ On / Linux OnDemand - Boost

テストケース1.2：BIOS TCの有効化 - CnQの有効化/ Linuxのパフォーマンス - 改善

テストケースグループ1の概要

テストケースグループ2：Bapmパッチを含むLinux + radeon

テストケース2.1：BIOS TC On - CnQ On / Linux OnDemand - Boost

テストケース2.2：BIOS TC On - CnQ On / Linuxパフォーマンス - 改善

テストケース 2.3: BIOS TC On - CnQ On/Linux OnDemand - ブーストなし

テストケース2.4：BIOS TC On - CnQ On / Linuxパフォーマンス - 改善なし

テストケース 2.5: BIOS TC オフ - CnQ オン/Linux OnDemand - ブースト

テストケース2.6：BIOS TCをオンにする - CnQをオフにする/ Linux該当なし

テストケースグループ2のまとめ

テストケースグループ3：Linux + fglrx（Catalyst）

テストケース3.1：BIOS TC On - CnQ On / Linux OnDemand - Boost

テストケースグループ3の概要

消費電力のまとめ

包括的な結論

感謝の言葉

おすすめ記事