私の目標は、アイドルモードでは消費電力が少ないですが、使用時には良いパフォーマンスを提供するミニサーバー(HTPCではない)を構築することです。可用性よりもデータセキュリティに重点を置いています。つまり、品質の良い部品ですが、保管時の冗長性のためにのみ使用されます。
私自身が偏波的だとは思わず、いくつかの調査をした後、一部のAMDデスクトップAPUが良い価値を提供すると思います。
残りの質問は次のとおりです。
- GPUのアイドル状態は消費電力を削減し、CPUリソースを確保しますか?
- Cool'n'QuietとTurbo Coreはアイドルモードでは予想される低消費電力を達成しますが、負荷時に高いパフォーマンスを達成しますか?
- Linuxは予想通りこのシナリオをサポートしますか?かなりの質問とフォーラムの議論は、これが必ずしもそうではないことを示しているようです。
答え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ドライバのパラメータはbapm
Kaveri、Kabini、およびデスクトップTrinity、Richlandシステムに対してデフォルトで設定されています。]
バラより[フル]radeon drm-fixes-3.16。
ただし、3.16ベースのDebianでは起動パラメータが機能しますが、デフォルトは(まだ?)機能しないようです。バラより最大のエネルギー効率とコンピューティング効率のためにAMD Turbo Core APUを搭載したDebianシステム(2D中心またはコンソール/サーバー)を設定するには?
[編集:無料のRadeonドライバにはすぐにbapm
パラメータがある予定です。]
結論は、radeon
APUの無料ドライバのパッチバージョンを使用して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
場所は/sys
Turbo 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)。ABS
PKGBUILD
pkgbase=linux-tc
makepkg --nobuildpi->enable_bapm = true;
trinity_dpm_init()
src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.c
makepkg --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.xzGRUB
grub-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はすぐに機能します。fglrx
radeon
fglrx
radeon
テストケース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 1
and
taskset -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を選んだ私の決定は大きな間違いでした。