Tujuan saya adalah menyiapkan server mini (bukan HTPC) dengan konsumsi daya rendah dalam mode siaga, namun menawarkan kinerja yang baik saat digunakan. Fokusnya lebih pada keamanan data daripada ketersediaan. Dengan kata lain: bagian berkualitas, tetapi redundansi hanya untuk penyimpanan.

Tidak menganggap diri saya bias, setelah beberapa penelitian saya merasa bahwa beberapa APU desktop AMD akan menawarkan nilai yang baik.

Pertanyaan yang tersisa adalah:

• Akankah keadaan siaga GPU menurunkan konsumsi daya dan mengeluarkan sumber daya untuk CPU?
• Akankah Cool'n'Quiet dan Turbo Core mengarah pada konsumsi daya rendah yang dimaksudkan dalam mode siaga tetapi kinerja di bawah beban?
• Apakah Linux mendukung skenario ini sebagaimana dimaksud? Cukup banyak pertanyaan dan diskusi di forum tampaknya menyarankan bahwa ini belum tentu demikian.

[Sunting: Kesimpulan pemikiran tentang pilihan prosesor]

• AMD vs AMD:
  • Richland melakukan pekerjaan yang jauh lebih baik daripada Trinity di sini.
  • Kaveri tidak dapat bersaing dengan disipasi daya mode diam Richland (setidaknya untuk saat ini).
  • GPU A10-6700 mungkin dinilai terlalu tinggi, tetapi agak menyedihkan itu tidak akan banyak digunakan. Beberapa algoritma mungkin dapat menggunakan kekuatan komputasinya. Tidak tahu bagaimana itu akan mempengaruhi konsumsi daya prosesor.
  • Saya menduga A10-6790K menjadi prosesor yang sama dengan A10-6700 hanya dengan parameter yang berbeda untuk Turbo Core. Jika ini benar, A10-6790K akan dapat meningkatkan lebih lama dan / atau memberikan frekuensi yang lebih tinggi dalam jangka panjang karena TDP yang lebih tinggi. Tetapi Anda akan membutuhkan kipas CPU yang berbeda untuk itu (pikirkan ruang dan suhu / rentang hidup).
• AMD A10-6700 vs Intel Core i3-3220:
  • A10-6700 memiliki lebih banyak kekuatan GPU, yang tidak digunakan di sini.
  • I3-3220 memiliki disipasi daya mode siaga lebih rendah.
  • Sementara pada tolok ukur tipikal, i3-3220 lebih cepat untuk perhitungan, saya tidak bisa melihat bagaimana dua core hyper-threading dapat menangani permintaan paralel (katakanlah, ke database dengan antarmuka web) secepat empat core berfitur lengkap (setidaknya ketika mengasumsikan caching serius). Namun, tidak menemukan tolok ukur yang serius - Hanya beberapa indikasi.

[Sunting: bapmParameter driver radeon gratis ditetapkan secara default untuk Kaveri, Kabini dan desktop Trinity, sistem Richland pada Linux 3.16]

Lihat [tarik] radeon drm-fixes-3.16 .

Namun, mengenai Debian berbasis 3.16, standarnya tidak (belum?) Tampaknya berfungsi, sedangkan parameter booting tidak. Lihat Bagaimana mengatur sistem Debian (fokus pada 2D atau konsol / server) dengan AMD Turbo Core APU untuk energi maksimum dan efisiensi komputasi?

[Edit: Driver radeon gratis akan segera memiliki bapmparameter]

Karena garis bawah di bawah ini adalah untuk menggunakan versi patch dari radeondriver gratis dengan APU Anda untuk mendukung Turbo Core dan mendapatkan hasil maksimal dari itu (kecuali grafis 3D yang) jika Anda bisa (memungkinkan bapmdapat menyebabkan ketidakstabilan dalam beberapa konfigurasi ), ini berita bagus bahwa radeon versi masa depan akan memiliki parameter untuk mengaktifkan bapm .

[Posting asli berikut]

Pengalaman APU AMD A10-6700 (Richland)

Pilihan Prosesor

PC pertama saya adalah 486DX2-66 yang dibuat dari puluhan floppy disk 3,5 "berisi paket sumber Slackware. Kalau begitu, banyak hal telah berubah, dan banyak industri saat ini tampaknya berada dalam fase di mana mereka masih menambah jumlah varian produk.

Keadaan ini dan beberapa keputusan AMD yang tidak menguntungkan di masa lalu belum membuat saya lebih mudah untuk memutuskan platform untuk server mini. Namun akhirnya, saya memutuskan bahwa A10-6700 akan menjadi pilihan yang baik:

• Beberapa ulasan menunjukkan bahwa Kaveri (masih banyak tidak tersedia) akan mengkonsumsi lebih banyak daya dalam mode siaga daripada Richland atau Trinity
• Keuntungan dari Richland A10-6700 dibandingkan Trinity A10-5700 tampaknya signifikan: Turunkan frekuensi terendah dan tertinggi tertinggi, Turbo Core berbutir lebih halus (mempertimbangkan juga suhu - cukup menguntungkan ketika GPU akan diam)
• GPU A10-6700 dikatakan terlalu tinggi (penamaan yang didorong oleh pemasaran) dan harga APU tampaknya adil

Komponen dan Pengaturan Lainnya

Meskipun prosesor yang tak terhitung jumlahnya dapat dipilih, tidak ada banyak papan Mini-ITX yang tersedia. ASRock FM2A78M-ITX + tampaknya menjadi pilihan yang masuk akal. Tes ini dilakukan dengan firmware V1.30 (tidak ada pembaruan saat saya menulis ini).

Hanya 80% dari output nominal catu daya yang harus dikonsumsi. Di sisi lain, banyak yang gagal bekerja secara efisien di bawah beban 50%. Sangat sulit untuk menemukan catu daya yang efisien energi untuk suatu sistem dengan kisaran perkiraan disipasi daya 35W hingga 120W. Saya melakukan tes ini dengan Seasonic G360 80+ Gold karena mengungguli sebagian besar pesaing mengenai efisiensi pada beban rendah.

Dua 8GB DDR3-1866 RAM (dikonfigurasi seperti itu - yang membuat perbedaan dibandingkan dengan 1333), satu drive SSD dan kipas CPU kualitas kontroleld PWM juga merupakan bagian dari pengaturan pengujian.

Pengukuran dilakukan dengan menggunakan AVM Fritz! DECT 200 yang telah dilaporkan melakukan pengukuran yang akurat. Namun, masuk akal divalidasi menggunakan perangkat tanpa nama yang lebih tua. Tidak ada inkonsistensi yang dapat diidentifikasi. Disipasi daya sistem yang terukur akan mencakup penurunan efisiensi catu daya untuk beban yang lebih rendah.

Layar QHD [W] terhubung melalui HDMI.

Memori bersama awal untuk GPU diatur ke 32M di UEFI BIOS. Juga, GPU Onboard dipilih sebagai Utama, dan IOMMU diaktifkan.

Tidak ada X atau sistem grafis lain yang dipasang atau dikonfigurasi. Output video dibatasi untuk mode konsol.

Dasar-dasar

Ada beberapa hal yang perlu diketahui.

• Sementara keputusan tentang Cool'n'Quiet dibuat oleh perangkat lunak di luar prosesor, Turbo Core adalah keputusan yang dibuat secara mandiri oleh mikrokontroler tambahan pada APU (atau CPU).
• Banyak alat serta /procdan /systempat tidak melaporkan aktivitas Turbo Core. cpufreq-aperf, cpupower frequency-infodan cpupower monitorlakukan, tetapi hanya setelah modprobe msr.

Grup Uji Kasus 1: Linux + radeon

Saya mulai dengan Arch Linux yang baru (installer 2014.08.01, kernel 3.15.7). Faktor kunci di sini adalah keberadaan acpi_cpufreq(skala CPU kernel) dan radeon(driver GPU kernel) dan cara mudah untuk menambal radeon.

Test Case 1.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

UEFI BIOS Pengaturan Inti Turbo ............................ Diaktifkan
Pengaturan UEFI BIOS Cool'n'Quiet .......................... Diaktifkan
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"info frekuensi cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Mengamati rentang cpu MHz "/ proc / cpuinfo" ... 1800 - 3700
Diamati "monitor cpupower" Rentang freq ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... tingkat daya 0

Muat | Frekuensi Inti
--------------- + -----------
stres --cpu 1 | 1 x 3700
stres --cpu 2 | 2 x 3700
stres --cpu 3 | 3 x 3700
stres --cpu 4 | 4 x 3700

Test Case 1.2: BIOS TC on - CnQ on / Kinerja Linux - Boost

UEFI BIOS Pengaturan Inti Turbo ............................ Diaktifkan
Pengaturan UEFI BIOS Cool'n'Quiet .......................... Diaktifkan
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... kinerja 

"info frekuensi cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Mengamati rentang cpu MHz "/ proc / cpuinfo" ... 3700
Diamati "monitor cpupower" Rentang freq ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... tingkat daya 0

Muat | Frekuensi Inti
--------------- + -----------
stres --cpu 1 | 1 x 3700
stres --cpu 2 | 2 x 3700
stres --cpu 3 | 3 x 3700
stres --cpu 4 | 4 x 3700

Ringkasan Test Case Group 1

Turbo Core meningkatkan berbasis tidak mungkin dalam skenario ini karena para radeonpengemudi saat menonaktifkan bapmbendera karena masalah stabilitas dalam beberapa skenario . Oleh karena itu, pengujian lebih lanjut dilewati.

Grup Uji Kasus 2: Linux + radeon bapm-patched

Untuk memungkinkan bapm, saya mulai dengan Arch Linux segar (installer 2014/08/01, kernel 3.15.7), mendapat saya core linuxpaket via ABS(3.15.8), mengedit PKGBUILDpenggunaan pkgbase=linux-tc, menarik sumber dengan makepkg --nobuild, berubah pi->enable_bapm = true;di trinity_dpm_init()dalam src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.c, dan dikompilasi dengan makepkg --noextract. Kemudian, saya menginstalnya ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzdan pacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz) dan memperbarui GRUB( grub-mkconfig -o /boot/grub/grub.cfgtapi, tentu saja, YMMV).

Akibatnya, saya diberi pilihan untuk boot linuxatau linux-tc, dan tes berikut merujuk pada yang terakhir.

Test Case 2.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

UEFI BIOS Pengaturan Inti Turbo ............................ Diaktifkan
Pengaturan UEFI BIOS Cool'n'Quiet .......................... Diaktifkan
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"info frekuensi cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Mengamati rentang cpu MHz "/ proc / cpuinfo" ... 1800 - 3700
Diamati "monitor cpupower" Rentang freq ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... tingkat daya 0

Muat | Frekuensi Inti
--------------- + -----------------
stres --cpu 1 | 1 x 4300
stres --cpu 2 | 2 x 4200 .. 4100
stres --cpu 3 | 3 x 4100 .. 3900
stres --cpu 4 | 4 x 4000 .. 3800

Test Case 2.2: BIOS TC on - CnQ on / Kinerja Linux - Boost

UEFI BIOS Pengaturan Inti Turbo ............................ Diaktifkan
Pengaturan UEFI BIOS Cool'n'Quiet .......................... Diaktifkan
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"info frekuensi cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Mengamati rentang cpu MHz "/ proc / cpuinfo" ... 3700
Diamati "monitor cpupower" rentang Freq ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... tingkat daya 0

Muat | Frekuensi Inti
--------------- + -----------------
stres --cpu 1 | 1 x 4300
stres --cpu 2 | 2 x 4200 .. 4100
stres --cpu 3 | 3 x 4100 .. 3900
stres --cpu 4 | 4 x 4000 .. 3800

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

UEFI BIOS Pengaturan Inti Turbo ............................ Diaktifkan
Pengaturan UEFI BIOS Cool'n'Quiet .......................... Diaktifkan
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand

"info frekuensi cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Mengamati rentang cpu MHz "/ proc / cpuinfo" ... 1800 - 3700
Diamati "monitor cpupower" Rentang freq ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... tingkat daya 1

Muat | Frekuensi Inti
--------------- + -----------
stres --cpu 1 | 1 x 3700
stres --cpu 2 | 2 x 3700
stres --cpu 3 | 3 x 3700
stres --cpu 4 | 4 x 3700

Test Case 2.4: BIOS TC on - CnQ on / Kinerja Linux - No Boost

UEFI BIOS Pengaturan Inti Turbo ............................ Diaktifkan
Pengaturan UEFI BIOS Cool'n'Quiet .......................... Diaktifkan
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"info frekuensi cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Mengamati rentang cpu MHz "/ proc / cpuinfo" ... 3700
Diamati "monitor cpupower" Rentang freq ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... tingkat daya 1

Muat | Frekuensi Inti
--------------- + -----------
stres --cpu 1 | 1 x 3700
stres --cpu 2 | 2 x 3700
stres --cpu 3 | 3 x 3700
stres --cpu 4 | 4 x 3700

Test Case 2.5: BIOS TC mati - CnQ on / Linux OnDemand - Boost

UEFI BIOS Pengaturan Inti Turbo ............................ Dinonaktifkan
Pengaturan UEFI BIOS Cool'n'Quiet .......................... Diaktifkan
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"info frekuensi cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Mengamati rentang cpu MHz "/ proc / cpuinfo" ... 1800 - 3700
Diamati "monitor cpupower" Rentang freq ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... tingkat daya 0

Dengan kata lain, jika Turbo Core dinonaktifkan di BIOS, tambalan radeontidak akan menyalakannya.

Test Case 2.6: BIOS TC on - CnQ off / Linux n / a

UEFI BIOS Pengaturan Inti Turbo ............................ Diaktifkan
Pengaturan UEFI BIOS Cool'n'Quiet .......................... Dinonaktifkan
/ sys / devices / system / cpu / cpufreq / boost ................... n / a
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... n / a

"info frekuensi cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Mengamati rentang cpu MHz "/ proc / cpuinfo" ... 3700
Diamati "monitor cpupower" rentang Freq ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... tingkat daya 0

Muat | Frekuensi Inti
--------------- + -----------------
stres --cpu 1 | 1 x 4300
stres --cpu 2 | 2 x 4100 .. 4000
stres --cpu 3 | 3 x 4000 .. 3800
stres --cpu 4 | 4 x 3900 .. 3700

Dengan Cool'n'Qiet dinonaktifkan, kernel Linux tidak akan menawarkan pilihan gubernur dan (salah) mengasumsikan bahwa core berjalan pada frekuensi tetap. Menariknya, frekuensi Turbo Core yang dihasilkan adalah yang terburuk dari semua kombinasi yang diuji dalam Grup Kasus Uji 2.

Ringkasan Test Case Group 2

Dengan radeondriver yang ditambal , Turbo Core berfungsi. Tidak ada ketidakstabilan (yang merupakan alasan mengapa bapmTurbo Core dinonaktifkan di sana) telah terlihat sejauh ini.

Grup Uji Kasus 3: Linux + fglrx (katalis)

Saya mulai dengan instalasi Ubuntu (14.04 Server, kernel 3.13) yang baru, yang saya lihat sebanding dengan Arch Linux (installer 2014.08.01, kernel 3.15.7) karena adanya acpi_cpufreq(penskalaan CPU kernel) dan radeon(driver GPU kernel) ). Alasan untuk beralih ke Ubuntu adalah kemudahan instalasi fglrx. Saya memvalidasi konsumsi daya dan perilaku dengan instalasi baru, yang menggunakan radeon.

Saya menginstal fglrxdari baris perintah ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) dan reboot sistem. Perubahan dari radeonmenjadi fglrxsegera jelas baik mengenai tampilan konsol ( fglrx: 128 x 48,: radeonjauh lebih tinggi) dan konsumsi daya mode siaga ( fglrx: 40W,: radeon30W). Tapi Turbo Core langsung bekerja.

Test Case 3.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

UEFI BIOS Pengaturan Inti Turbo ............................ Diaktifkan
Pengaturan UEFI BIOS Cool'n'Quiet .......................... Diaktifkan
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"info frekuensi cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Mengamati rentang cpu MHz "/ proc / cpuinfo" ... 1800 - 3700
Diamati "monitor cpupower" Rentang freq ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... n / a

Muat | Frekuensi Inti
--------------- + ----------------------------
stres --cpu 1 | 1 x 4300
stres --cpu 2 | 2 x 4200 .. 3900 (inti chg)
stres --cpu 3 | 3 x 4100 .. 3700
stres --cpu 4 | 4 x 4000 .. 3600

The fglrxperilaku pasti menarik. Ketika 'stress --cpu 2' dipanggil untuk salah satu test case dalam kelompok test case apa saja, kedua core yang dimuat selalu terletak pada modul yang terpisah. Tetapi dengan fglrx, realokasi tiba-tiba terjadi sehingga modul tunggal digunakan (yang menghemat daya lihat di bawah). Setelah beberapa waktu, inti yang dimuat kembali ke modul lainnya. Ini tidak terlihat dengan radeon. Mungkinkah yang fglrxmemanipulasi afinitas inti dari proses?

Ringkasan Test Case Group 3

Keuntungannya fglrxadalah memungkinkan Turbo Core segera, tanpa perlu menambalnya.

Karena fglrxmembuang 10 hingga 12W untuk GPU dalam skenario kami pada sebuah chip dengan 65W TDP, hasil keseluruhan mengenai kecepatan inti yang tersedia tidak mengesankan. Karena itu, tidak ada tes lebih lanjut yang dilakukan.

Juga dari sudut pandang teknik, perilaku fglrxtampaknya agak sedih. Alokasi kembali satu dari dua core yang sibuk ke modul lain untuk mempertahankan frekuensi yang lebih tinggi mungkin atau mungkin bukan ide yang baik, karena sebelum langkah itu, kedua core memiliki cache L2 mereka sendiri, sementara setelah itu, mereka harus berbagi satu. Apakah fglrxmempertimbangkan metrik apa pun (seperti cache hit missses) untuk mendukung keputusannya harus diklarifikasi secara terpisah, tetapi ada laporan lain tentang perilaku mendadaknya .

Ringkasan Konsumsi Daya

Beberapa nilai delta dalam tabel berikut menjadi sedikit lebih buruk ketika suhu naik; bisa dikatakan kipas yang dikendalikan PWM dan chip keduanya berperan di sana.

System @State / -> Transition Delta | Pembuangan Daya Sistem
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86W
  @ Bootloader | @ 108 .. 89W
  @Ubuntu Installer Idle | @ 40W
  @Linux radeon Idle ondemand | @ 30W
  @Linux radeon Performa siaga | @ 30W
  @Linux fglrx Idle ondemand | @ 40W
  1 Modul 1800 -> 3700 | + 13W
  1 Modul 1800 -> 4300 | + 25W
  1 Inti 1800 -> 3700 | + 5W
  1 Inti 1800 -> 4300 | + 10W
  "radeon" Video Out -> Nonaktifkan | - 2W
  'fglrx "Video Out -> Darken | + - 0W
  @Linux radeon Maksimum | @ 103 .. 89W
  @Linux fglrx Maksimum | @ 105 .. 92W

• Tampaknya ada lebih banyak ke Turbo Core (setidaknya dengan APU Richland) dari yang diharapkan: Tidak ada perbedaan yang nyata dalam disipasi daya ketika gubernur penskalaan "ondemand" berada di tempat dibandingkan dengan ketika gubernur "kinerja" berada di tempatnya. Althouth /proc/cpuinfoakan selalu melaporkan 37000MHz di bawah gubernur kinerja, cpupower monitorakan mengungkapkan bahwa core benar-benar melambat. Dalam beberapa kasus, frekuensi serendah 2000MHz ditunjukkan; mungkin saja 1800MHz secara internal akan digunakan juga.
• A10-6700 terdiri dari dua modul dengan masing-masing dua inti. Jika misalnya dua core menganggur dan dua core sibuk dan dipercepat, perilaku sistem akan berbeda tergantung pada apakah core sibuk terletak pada modul yang sama atau tidak.
  • Mempercepat modul lebih intensif energi daripada mempercepat inti.
  • Cache L2 ditugaskan per modul.
• Perbedaan antara disipasi daya dua core yang berakselerasi pada modul yang sama vs pada modul yang berbeda ditentukan dengan mengganti stress --cpu 2(yang selalu menyebabkan distribusi di antara dua modul) oleh .taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• A10-6700 tampaknya memiliki batas disipasi daya total untuk APU (92W bersama-sama dengan komponen lain) dengan sedikit dicadangkan untuk GPU saja (3 W). Dengan radeon, itu akan memungkinkan lebih banyak untuk jangka waktu pendek dan mengurangi ke maksimum dengan sangat lancar, sementara dengan fglrx, telah diamati bahwa batas-batas ini terlampaui lebih signifikan dan disipasi daya kemudian dikurangi secara tiba-tiba.
• Sementara banyak orang mengklaim bahwa keterlambatan ketersediaan Kaveri dimaksudkan oleh AMD karena akan membunuh APU mereka saat ini, saya mohon berbeda. Richland A10 telah menunjukkan manajemen daya yang sangat baik, dan Kaveri tidak dapat bersaing dengan konsumsi daya keadaan idle yang rendah (kompleksitas chip Kaveri hampir dua kali lipat dari Richland, sehingga akan mengambil satu atau dua langkah pengembangan lagi).

Kesimpulan Keseluruhan

• Termasuk suhu dalam logika Turbo Core (seperti yang dilaporkan untuk langkah Trinity -> Richland) tampaknya masuk akal dan tampaknya bekerja dengan baik, seperti yang dapat dilihat dengan pengurangan disipasi pwoer di BIOS dan Bootloader dari waktu ke waktu.
• Untuk skenario cosole / server, A10-6700 mendukung 4 core @ 3700MHz (3800MHz dengan Turbo Core) dalam jangka panjang, setidaknya dengan radeonpengemudi. Mungkin tidak ada banyak peluang untuk mempertahankan tingkat kinerja ini ketika GPU dapat dikerjakan.
• Tampaknya TDP 65W dapat secara permanen sedikit melebihi beban penuh, tetapi sulit untuk mengatakan karena catu daya memiliki efisiensi yang lebih rendah pada 30W. Karena ada indikasi yang jelas bahwa suhu dipertimbangkan (disipasi daya puncak hampir 110W diamati sebelum mulai berkurang menjadi 90W, dan juga 2 core pada 4300 MHz dilaporkan untuk beberapa waktu), investasi dalam pendinginan APU mungkin merupakan ide bagus. Namun, mainboards terbatas pada TDP 65W hanya akan dapat memasok begitu banyak saat ini, sehingga pasti akan ada batas keras yang dikenakan oleh APU.
• Jika Anda berniat menggunakan Richland APU untuk komputasi di Linux, Anda pasti ingin menggunakan radeondriver yang ditambal (jika Anda tidak menemui ketidakstabilan - khususnya sehubungan dengan mengaktifkan Dynamic Power Management). Jika tidak, Anda tidak akan mendapatkan nilai penuh.
• Anehnya, tampaknya pengaturan terbaik adalah mengaktifkan Turbo Core dan Cool'n'Quiet di BIOS tetapi kemudian memilih performancegubernur penskalaan - setidaknya jika APU Anda berperilaku seperti yang diuji di sini. Anda akan memiliki konsumsi daya yang sama dengan ondemandtetapi dengan penskalaan frekuensi yang lebih cepat dan overhead kernel yang lebih sedikit untuk membuat keputusan penskalaan.

Ucapan Terima Kasih

Terima kasih khusus kepada Alex Deucher, yang secara signifikan mendorong saya ke arah yang benar di bugzilla.kernel.org .

Saya terkesan dengan kualitas radeondriver gratis dan saya ingin mengucapkan terima kasih kepada seluruh tim untuk menjaga perangkat lunak ini, yang tampaknya direkayasa dengan cermat. Jika radeontidak berperilaku seperti itu, keputusan saya yang mendukung A10-6700 akan sangat salah.