私の目的は、アイドルモードでの消費電力が少なく、使用時に優れたパフォーマンスを提供するミニサーバー（HTPCではない）をセットアップすることです。焦点は、可用性よりもデータの安全性にあります。言い換えれば、高品質のパーツですが、冗長性はストレージのみです。
偏見があるとは考えていませんでしたが、いくつかの調査の結果、AMDデスクトップAPUの一部が優れた価値を提供すると感じました。
残りの質問は次のとおりです。
回答:
[編集：プロセッサの選択に関する結論]
[編集：無料のradeonドライバーのbapmパラメーターは、Linux 3.16の時点で、Kaveri、KabiniおよびデスクトップTrinity、Richlandシステムに対してデフォルトで設定されています]
[pull] radeon drm-fixes-3.16を参照してください。
ただし、3.16ベースのDebianに関しては、ブートパラメータは機能しますが、デフォルトは（まだ？）機能していないようです。最大のエネルギーとコンピューティング効率を得るために、AMD Turbo Core APUでDebianシステムをセットアップする方法（2Dまたはコンソール/サーバーに焦点を当てる）を参照してください。
[編集：無料のradeonドライバーにはまもなくbapmパラメーターが追加されます]
下記の一番下の行は、無料のパッチを適用したバージョンを使用することですので、radeonあなたが（有効にすることができればターボ・コアをサポートし、（ある3Dグラフィックスを除く）、そのほとんどアウトを得るためにあなたのAPUとドライバをbapmいくつかの構成での不安定性につながることができます）、radeonの将来のバージョンにbapmを有効にするパラメーターが含まれることは素晴らしいニュースです。
[元の投稿は次のとおりです]
私の最初のPCは、Slackwareソースパッケージを含む3.5インチの数十枚のフロッピーディスクからセットアップされた486DX2-66でした。その後、多くの変化があり、現在、多くの業界がまだ数を増やしている段階にあるようです製品バリエーションの。
このような状況と、最近のAMDの不幸な決定の一部により、ミニサーバーのプラットフォームを決定するのは簡単ではありませんでした。しかし最後に、私はA10-6700が良い選択であると決めました：
プロセッサの数は無数ですが、利用できるMini-ITXボードはそれほど多くありません。ASRock FM2A78M-ITX +が妥当な選択であるように思われました。テストはファームウェアV1.30で行われました（これを書いているのでアップデートはありません）。
電源の公称出力の80％だけが消費されます。一方、50％未満の負荷では、多くが効率的に機能しません。35Wから120Wの推定消費電力範囲を持つシステム用のエネルギー効率の高い電源を見つけることは非常に困難です。これらのテストは、低負荷での効率に関してほとんどの競合他社よりも優れているため、Seasonic G360 80+ゴールドで実施しました。
2つの8 GB DDR3-1866 RAM（そのように構成されている-これは1333と比べて違いがあります）、1つのSSDドライブ、およびPWM制御品質のCPUファンもテストセットアップの一部でした。
測定は、正確な測定を行うことが報告されているAVM Fritz！DECT 200を使用して行われました。それでも、古い名前のないデバイスを使用して妥当性が検証されました。不整合は確認できませんでした。測定されたシステム電力損失には、低負荷での電源の効率低下が含まれます。
[W] QHD画面がHDMI経由で接続されました。
GPUの初期共有メモリは、UEFI BIOSで32Mに設定されていました。また、オンボードGPUがプライマリとして選択され、IOMMUが有効になりました。
Xまたはその他のグラフィカルシステムはインストールまたは構成されていません。ビデオ出力はコンソールモードに制限されていました。
知っておくべきことがいくつかあります。
/procと/sys場所は、Turbo Coreアクティビティを報告しません。cpufreq-aperf、cpupower frequency-infoそしてcpupower monitorそうですが、その後だけmodprobe msrです。私は新しいArch Linux（インストーラー2014.08.01、カーネル3.15.7）から始めました。ここでの重要な要素は、acpi_cpufreq（カーネルCPUスケーリング）とradeon（カーネルGPUドライバー）の存在とパッチを適用する簡単な方法radeonです。
UEFI BIOS Turbo Core設定............................有効 UEFI BIOS Cool'n'Quiet Setting ..........................有効 / sys / devices / system / cpu / cpufreq / boost ................... 1 / sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ...オンデマンド
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観察された「/ proc / cpuinfo」CPU MHz範囲... 1800-3700 観察された「cpupowerモニター」の周波数範囲... 1800-3700 / sys / kernel / debug / dri / 0 / radeon_pm_info ...電力レベル0
ロード| コア周波数 --------------- + ----------- ストレス--cpu 1 | 1 x 3700 ストレス--cpu 2 | 2 x 3700 ストレス--cpu 3 | 3 x 3700 ストレス--cpu 4 | 4 x 3700
UEFI BIOS Turbo Core設定............................有効 UEFI BIOS Cool'n'Quiet Setting ..........................有効 / sys / devices / system / cpu / cpufreq / boost ................... 1 / sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ...パフォーマンス
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観察された「/ proc / cpuinfo」CPU MHz範囲... 3700 観察された「cpupowerモニター」の周波数範囲... 2000〜3700 / sys / kernel / debug / dri / 0 / radeon_pm_info ...電力レベル0
ロード| コア周波数 --------------- + ----------- ストレス--cpu 1 | 1 x 3700 ストレス--cpu 2 | 2 x 3700 ストレス--cpu 3 | 3 x 3700 ストレス--cpu 4 | 4 x 3700
このシナリオでは、ターボコアベースのブーストは不可能です。これは、一部のシナリオでの安定性の問題により、radeonドライバーが現在bapmフラグを無効にしているためです。したがって、それ以上のテストはスキップされました。
を有効bapmにするために、新しいArch Linux（インストーラー2014.08.01、カーネル3.15.7）から始め、（3.15.8）でcore linuxパッケージを入手ABSし、PKGBUILDを使用するようpkgbase=linux-tcに編集し、でソースをプルしmakepkg --nobuild、で変更pi->enable_bapm = true;しtrinity_dpm_init()ましたsrc/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.c。でコンパイルしましたmakepkg --noextract。次に、それをインストールし（pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzおよびpacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz）、更新しましたGRUB（grub-mkconfig -o /boot/grub/grub.cfgもちろん、YMMV）。
その結果、ブートlinuxまたはの選択が与えられlinux-tc、以下のテストでは後者を参照しています。
UEFI BIOS Turbo Core設定............................有効 UEFI BIOS Cool'n'Quiet Setting ..........................有効 / sys / devices / system / cpu / cpufreq / boost ................... 1 / sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ...オンデマンド
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観察された「/ proc / cpuinfo」CPU MHz範囲... 1800-3700 観察された「cpupowerモニター」の周波数範囲... 1800-4300 / sys / kernel / debug / dri / 0 / radeon_pm_info ...電力レベル0
ロード| コア周波数 --------------- + ----------------- ストレス--cpu 1 | 1 x 4300 ストレス--cpu 2 | 2 x 4200 .. 4100 ストレス--cpu 3 | 3 x 4100 .. 3900 ストレス--cpu 4 | 4 x 4000 .. 3800
UEFI BIOS Turbo Core設定............................有効 UEFI BIOS Cool'n'Quiet Setting ..........................有効 / sys / devices / system / cpu / cpufreq / boost ................... 1 / sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観察された「/ proc / cpuinfo」CPU MHz範囲... 3700 観察された「cpupowerモニター」の周波数範囲... 2000〜4300 / sys / kernel / debug / dri / 0 / radeon_pm_info ...電力レベル0
ロード| コア周波数 --------------- + ----------------- ストレス--cpu 1 | 1 x 4300 ストレス--cpu 2 | 2 x 4200 .. 4100 ストレス--cpu 3 | 3 x 4100 .. 3900 ストレス--cpu 4 | 4 x 4000 .. 3800
UEFI BIOS Turbo Core設定............................有効 UEFI BIOS Cool'n'Quiet Setting ..........................有効 / sys / devices / system / cpu / cpufreq / boost ................... 0 / sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ...オンデマンド
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観察された「/ proc / cpuinfo」CPU MHz範囲... 1800-3700 観察された「cpupowerモニター」の周波数範囲... 1800-3700 / sys / kernel / debug / dri / 0 / radeon_pm_info ...電力レベル1
ロード| コア周波数 --------------- + ----------- ストレス--cpu 1 | 1 x 3700 ストレス--cpu 2 | 2 x 3700 ストレス--cpu 3 | 3 x 3700 ストレス--cpu 4 | 4 x 3700
UEFI BIOS Turbo Core設定............................有効 UEFI BIOS Cool'n'Quiet Setting ..........................有効 / sys / devices / system / cpu / cpufreq / boost ................... 0 / sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観察された「/ proc / cpuinfo」CPU MHz範囲... 3700 観察された「cpupowerモニター」の周波数範囲... 2000〜3700 / sys / kernel / debug / dri / 0 / radeon_pm_info ...電力レベル1
ロード| コア周波数 --------------- + ----------- ストレス--cpu 1 | 1 x 3700 ストレス--cpu 2 | 2 x 3700 ストレス--cpu 3 | 3 x 3700 ストレス--cpu 4 | 4 x 3700
UEFI BIOS Turbo Core設定............................................無効 UEFI BIOS Cool'n'Quiet Setting ..........................有効 / sys / devices / system / cpu / cpufreq / boost ................... 1 / sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ...オンデマンド
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観察された「/ proc / cpuinfo」CPU MHz範囲... 1800-3700 観察された「cpupowerモニター」の周波数範囲... 1800-3700 / sys / kernel / debug / dri / 0 / radeon_pm_info ...電力レベル0
つまり、BIOSでTurbo Coreが無効になっている場合、パッチを適用してradeonも有効になりません。
UEFI BIOS Turbo Core設定............................有効 UEFI BIOS Cool'n'Quiet Setting ..........................無効 / sys / devices / system / cpu / cpufreq / boost ................... n / a / sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... n / a
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観察された「/ proc / cpuinfo」CPU MHz範囲... 3700 観察された「cpupowerモニター」の周波数範囲... 2000〜4300 / sys / kernel / debug / dri / 0 / radeon_pm_info ...電力レベル0
ロード| コア周波数 --------------- + ----------------- ストレス--cpu 1 | 1 x 4300 ストレス--cpu 2 | 2 x 4100 .. 4000 ストレス--cpu 3 | 3 x 4000 .. 3800 ストレス--cpu 4 | 4 x 3900 .. 3700
Cool'n'Qietを無効にすると、Linuxカーネルはガバナーの選択を提供せず、（誤って）コアが固定周波数で実行されると想定します。興味深いことに、結果として得られるターボコア周波数は、テストケースグループ2でテストされたすべての組み合わせの中で最悪です。
パッチを当てたradeonドライバーを使用すると、Turbo Coreが機能します。bapmこれまでのところ、不安定性（別名Turbo Coreがそこで無効にされている理由）は確認されていません。
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）からインストールし、システムを再起動しました。からradeonへの変更fglrxは、コンソールの外観（fglrx：128 x 48 、：radeonはるかに高い）とアイドルモードの消費電力（fglrx：40W、radeon：30W）の両方に関してすぐにわかります。しかし、Turbo Coreはすぐに動作します。
UEFI BIOS Turbo Core設定............................有効 UEFI BIOS Cool'n'Quiet Setting ..........................有効 / sys / devices / system / cpu / cpufreq / boost ................... 1 / sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ...オンデマンド
"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800 観察された「/ proc / cpuinfo」CPU MHz範囲... 1800-3700 観察された「cpupowerモニター」の周波数範囲... 1800-4300 / sys / kernel / debug / dri / 0 / radeon_pm_info ... n / a
ロード| コア周波数 --------------- + ---------------------------- ストレス--cpu 1 | 1 x 4300 ストレス--cpu 2 | 2 x 4200 .. 3900（コア変更） ストレス--cpu 3 | 3 x 4100 .. 3700 ストレス--cpu 4 | 4 x 4000 .. 3600
fglrx行動は間違いなく面白いです。'stress --cpu 2'が任意のテストケースグループのtesケースに対して呼び出されたとき、2つのロードされたコアは常に別々のモジュールに配置されていました。しかし、fglrxを使用すると、単一のモジュールが使用されるような突然の再割り当てが発生しました（これにより、かなりの電力が節約されます（下記参照）。しばらくすると、ロードされたコアが他のモジュールに戻りました。これはで見られませんでしたradeon。fglrxプロセスのコアアフィニティを操作するのでしょうか。
の利点fglrxは、パッチを適用する必要なしに、Turbo Coreをすぐに有効にすることです。
のでfglrx65W TDPとチップ上の私たちのシナリオではGPUのための12Wに廃棄物10は、利用可能なコア速度に関する全体的な結果が印象的です。したがって、それ以上のテストは行われませんでした。
エンジニアリングの観点からも、の動作はfglrx少し悲しいようです。より高い周波数を維持するために2つのビジーコアの1つを他のモジュールに再割り当てすることは良い考えかもしれませんし、そうでないかもしれません。そのステップの前に、両方のコアは独自のL2キャッシュを持っていましたが、その後、それらは1つを共有する必要があるためです。fglrxその決定をサポートするためにメトリック（キャッシュヒットミスなど）を考慮するかどうかは、個別に明確にする必要がありますが、その急激な動作に関する他のレポートがあります。
次の表のデルタ値のいくつかは、温度が上昇するにつれてわずかに悪化します。そこでは、PWM制御ファンとチップの両方が役割を果たしていると言えます。
システム@State /-> Transition Delta | システムの電力損失 ------------------------------------- + ------------ ------------- @BIOS | @ 95 .. 86W @ブートローダー| @ 108 .. 89W @Ubuntuインストーラーアイドル| @ 40W @Linux radeon Idle ondemand | @ 30W @Linux radeonアイドルパフォーマンス| @ 30W @Linux fglrx Idle ondemand | @ 40W 1モジュール1800-> 3700 | + 13 W 1モジュール1800-> 4300 | + 25W 1コア1800-> 3700 | + 5W 1コア1800-> 4300 | + 10W "radeon"ビデオ出力->無効| -2W 'fglrx "ビデオ出力->暗くする| +-0W @Linux radeon Maximum | @ 103 .. 89W @Linux fglrx Maximum | @ 105 .. 92W
/proc/cpuinfoは常にパフォーマンスガバナーの下で37000MHz を報告cpupower monitorし、コアが実際にスローダウンすることを明らかにします。場合によっては、2000MHzという低い周波数が表示されました。内部で1800MHzも使用される可能性があります。andtaskset -c 1 stress --cpu 1radeonすると、短時間でより多くのことが可能になり、非常にスムーズに最大値まで減少しますが、を使用するとfglrx、これらの制限を大幅に超え、電力損失が急激に減少することが確認されています。radeonドライバーを使用して、長期にわたって3700MHz（ターボコアでは3800MHz）で4コアをサポートします。GPUが処理を行うときに、このパフォーマンスレベルを維持するチャンスはおそらくありません。radeonドライバーを使用することをお勧めします（特に動的電源管理の有効化と組み合わせて不安定さが発生しない場合）。それ以外の場合は、完全な値を取得できません。performanceスケーリングガバナーを選択するのが最適なセットアップのようです-少なくともAPUがここでテストしたものと同じように動作する場合は。と同じ電力消費が得られますがondemand、スケーリングを決定するために、周波数スケーリングが高速になり、カーネルのオーバーヘッドが少なくなります。Bugzilla.kernel.orgで私を正しい方向に向けてくれたAlex Deucherに特に感謝します。
私はフリーradeonドライバーの品質に感銘を受けており、慎重に設計されたように見えるこのソフトウェアをメンテナンスしてくれたチーム全体に感謝します。もしそれradeonがそのように振る舞わないならば、A10-6700を支持する私の決定は実質的に間違っていただろう。