Mục tiêu của tôi là thiết lập một máy chủ mini (không phải HTPC) với mức tiêu thụ điện năng thấp ở chế độ không tải, nhưng vẫn cung cấp hiệu suất tốt khi sử dụng. Trọng tâm là an toàn dữ liệu hơn là sẵn có. Nói cách khác: phần chất lượng, nhưng dự phòng chỉ để lưu trữ.

Không coi bản thân là thiên vị, sau một số nghiên cứu tôi cảm thấy rằng một số APU máy tính để bàn AMD sẽ cung cấp giá trị tốt.

Các câu hỏi còn lại là:

• Trạng thái nhàn rỗi của GPU sẽ giảm mức tiêu thụ năng lượng và giải phóng tài nguyên cho CPU?
• Cool'n'Quiet và Turbo Core sẽ dẫn đến mức tiêu thụ năng lượng thấp dự định ở chế độ không tải nhưng hiệu suất khi tải?
• Linux sẽ hỗ trợ kịch bản này như dự định? Khá nhiều câu hỏi và thảo luận diễn đàn dường như cho thấy rằng điều này không nhất thiết phải như vậy.

[Chỉnh sửa: Kết luận những suy nghĩ liên quan đến lựa chọn bộ xử lý]

• AMD vs AMD:
  • Richland làm một công việc tốt hơn nhiều so với Trinity ở đây.
  • Kaveri không thể cạnh tranh với sự phân tán năng lượng nhàn rỗi của Richland (ít nhất là bây giờ).
  • GPU của A10-6700 có thể được đánh giá quá cao, nhưng hơi buồn là nó sẽ không được sử dụng nhiều. Một số thuật toán có thể có thể triển khai sức mạnh tính toán của nó. Dù vậy, không biết điều đó sẽ ảnh hưởng đến mức tiêu thụ năng lượng của bộ xử lý như thế nào.
  • Tôi nghi ngờ A10-6790K là bộ xử lý tương tự A10-6700 chỉ với một bộ thông số khác nhau cho các lần tăng tốc Turbo Core. Nếu điều này là đúng, A10-6790K sẽ có thể tăng thời gian dài hơn và / hoặc cung cấp tần số cao hơn trong dài hạn do TDP cao hơn. Nhưng bạn sẽ cần một quạt CPU khác cho điều đó (nghĩ về không gian và nhiệt độ / tuổi thọ).
• AMD A10-6700 so với Intel Core i3-3220:
  • A10-6700 có nhiều sức mạnh GPU hơn, không được sử dụng ở đây.
  • I3-3220 có mức tiêu thụ năng lượng ở chế độ không tải thấp hơn.
  • Mặc dù trong các điểm chuẩn điển hình, i3-3220 nhanh hơn cho việc tính toán, tôi không thể thấy hai lõi siêu phân luồng của nó có thể xử lý các yêu cầu song song như thế nào đối với cơ sở dữ liệu có giao diện web) nhanh như bốn lõi có tính năng đầy đủ (ít nhất là khi giả định một số bộ nhớ đệm nghiêm trọng). Mặc dù vậy, không tìm thấy bất kỳ điểm chuẩn nghiêm trọng nào - Chỉ một số dấu hiệu.

[Chỉnh sửa: bapmThông số của trình điều khiển radeon miễn phí được đặt theo mặc định cho Kaveri, Kabini và máy tính để bàn Trinity, hệ thống Richland kể từ Linux 3.16]

Xem [kéo] radeon drm-fixes-3.16 .

Tuy nhiên, liên quan đến Debian dựa trên 3.16, các mặc định không (chưa?) Dường như hoạt động, trong khi tham số khởi động thì có. Xem Cách thiết lập hệ thống Debian (tập trung vào 2D hoặc bàn điều khiển / máy chủ) với APU AMD Turbo Core để đạt hiệu quả năng lượng và tính toán tối đa?

[Chỉnh sửa: Trình điều khiển radeon miễn phí sẽ sớm có một bapmtham số]

Vì điểm mấu chốt dưới đây là sử dụng phiên bản vá của radeontrình điều khiển miễn phí với APU của bạn để hỗ trợ Turbo Core và tận dụng tối đa (trừ đồ họa 3D) nếu bạn có thể (cho phép bapmcó thể dẫn đến sự không ổn định trong một số cấu hình ), một tin tuyệt vời là các phiên bản tương lai của radeon sẽ có một tham số để kích hoạt bapm .

[Bài viết gốc sau]

Trải nghiệm APU AMD A10-6700 (Richland)

Lựa chọn bộ xử lý

PC đầu tiên của tôi là 486DX2-66 được thiết lập từ hàng chục đĩa mềm 3,5 "chứa các gói nguồn Slackware. Sice sau đó, rất nhiều thứ đã thay đổi, và nhiều ngành công nghiệp hiện đang trong giai đoạn mà chúng vẫn tăng số lượng của các biến thể sản phẩm.

Tình huống này và một số quyết định đáng tiếc của AMD trong quá khứ gần đây không giúp tôi dễ dàng quyết định nền tảng cho một máy chủ mini. Nhưng cuối cùng, tôi đã quyết định rằng A10-6700 sẽ là một lựa chọn tốt:

• Một số đánh giá đã chỉ ra rằng một Kaveri (vẫn không có sẵn rộng rãi) sẽ tiêu thụ nhiều năng lượng hơn ở chế độ không tải so với Richland hoặc Trinity
• Lợi thế của Richland A10-6700 so với Trinity A10-5700 dường như rất đáng kể: Tần số thấp nhất và tần số cao nhất thấp hơn, lõi Turbo mịn hơn (xem xét cả nhiệt độ - khá là một lợi thế khi GPU sẽ không hoạt động)
• GPU của A10-6700 được cho là được đánh giá quá cao (đặt tên theo hướng tiếp thị) và giá của APU có vẻ công bằng

Các thành phần và thiết lập khác

Mặc dù có vô số bộ xử lý để lựa chọn, vẫn không có nhiều bảng Mini-ITX. ASRock FM2A78M-ITX + dường như là một lựa chọn hợp lý. Thử nghiệm đã được thực hiện với phần mềm v1.30 (không có bản cập nhật nào khi tôi viết bài này).

Chỉ nên tiêu thụ 80% sản lượng danh nghĩa của nguồn điện. Mặt khác, nhiều người không làm việc hiệu quả dưới tải 50%. Rất khó để tìm được nguồn cung cấp năng lượng hiệu quả cho một hệ thống có dải công suất tiêu tán ước tính từ 35W đến 120W. Tôi đã thực hiện các thử nghiệm này với Seasonic G360 80+ Gold vì nó vượt trội so với hầu hết các đối thủ cạnh tranh về hiệu quả ở mức tải thấp.

Hai RAM 8GB DDR3-1866 (được cấu hình như vậy - tạo ra sự khác biệt so với 1333), một ổ SSD và quạt CPU chất lượng điều khiển PWM cũng là một phần của thiết lập thử nghiệm.

Các phép đo được thực hiện bằng AVM Fritz! DECT 200 đã được báo cáo để thực hiện các phép đo chính xác. Tuy nhiên, tính hợp lý đã được xác thực bằng cách sử dụng một thiết bị không tên cũ hơn. Không có sự không nhất quán có thể được xác định. Công suất tiêu tán của hệ thống đo được sẽ bao gồm hiệu suất giảm của nguồn cung cấp cho các tải thấp hơn.

Màn hình [W] QHD được kết nối qua HDMI.

Bộ nhớ chia sẻ ban đầu cho GPU được đặt thành 32M trong UEFI BIOS. Ngoài ra, GPU Onboard được chọn là Chính và IOMMU đã được bật.

Không có X hoặc hệ thống đồ họa khác được cài đặt hoặc cấu hình. Đầu ra video bị hạn chế ở chế độ console.

Khái niệm cơ bản

Có một vài điều người ta cần biết.

• Mặc dù quyết định về Cool'n'Quiet được đưa ra bởi phần mềm bên ngoài bộ xử lý, Turbo Core là quyết định được đưa ra tự động bởi một bộ vi điều khiển bổ sung trên APU (hoặc CPU).
• Nhiều công cụ cũng như /procvà /sysnhững nơi không báo cáo hoạt động Turbo Core. cpufreq-aperf, cpupower frequency-infovà cpupower monitorlàm, nhưng chỉ sau modprobe msr.

Trường hợp thử nghiệm Nhóm 1: Linux + radeon

Tôi đã bắt đầu với Arch Linux mới (trình cài đặt 2014.08.01, kernel 3.15.7). Yếu tố chính ở đây là sự hiện diện của acpi_cpufreq(nhân CPU CPU) và radeon(trình điều khiển GPU kernel) và cách dễ dàng để vá radeon.

Trường hợp thử nghiệm 1.1: BIOS TC trên - CnQ on / Linux OnDemand - Boost

Thiết lập lõi Turbo của UEFI ............................ Đã bật
Cài đặt UEFI BIOS Cool'n'Quiet .......................... Đã bật
/ sys / thiết bị / hệ thống / cpu / cpufreq / boost ................... 1
/ sys / thiết bị / hệ thống / cpu / cpu * / cpufreq / scaling_gocateor ... ondemand 

"Thông tin tần số cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Phạm vi cpu MHz "/ Proc / cpuinfo" được quan sát ... 1800 - 3700
Phạm vi Freq "màn hình cpupower" được quan sát ... 1800 - 3700
/ sys / kernel / debug / Dri / 0 / radeon_pm_info ... mức năng lượng 0

Tải | Freq cốt lõi
--------------- + -----------
căng thẳng - lõi 1 | 1 x 3700
căng thẳng --cpu 2 | 2 x 3700
căng thẳng - cpu 3 | 3 x 3700
căng thẳng - cpu 4 | 4 x 3700

Trường hợp thử nghiệm 1.2: BIOS TC trên - Hiệu suất CnQ trên / Linux - Tăng cường

Thiết lập lõi Turbo của UEFI ............................ Đã bật
Cài đặt UEFI BIOS Cool'n'Quiet .......................... Đã bật
/ sys / thiết bị / hệ thống / cpu / cpufreq / boost ................... 1
/ sys / thiết bị / hệ thống / cpu / cpu * / cpufreq / scaling_gocateor ... hiệu suất 

"Thông tin tần số cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Phạm vi cpu MHz "/ Proc / cpuinfo" được quan sát ... 3700
Phạm vi Freq "màn hình cpupower" được quan sát ... 2000 - 3700
/ sys / kernel / debug / Dri / 0 / radeon_pm_info ... mức năng lượng 0

Tải | Freq cốt lõi
--------------- + -----------
căng thẳng - lõi 1 | 1 x 3700
căng thẳng --cpu 2 | 2 x 3700
căng thẳng - cpu 3 | 3 x 3700
căng thẳng - cpu 4 | 4 x 3700

Tóm tắt Test Case Nhóm 1

Turbo Core dựa tăng các là không thể trong trường hợp này bởi vì các radeontài xế hiện vô hiệu hóa các bapmlá cờ do các vấn đề ổn định trong một số tình huống . Do đó, thử nghiệm thêm đã bị bỏ qua.

Trường hợp thử nghiệm Nhóm 2: radeon vá Linux + bapm

Để kích hoạt bapm, tôi bắt đầu với một Arch Linux tươi (cài đặt 2014/08/01, kernel 3.15.7), đã cho tôi những core linuxgói qua ABS(3.15.8), chỉnh sửa PKGBUILDđể sử dụng pkgbase=linux-tc, kéo các nguồn với makepkg --nobuild, thay đổi pi->enable_bapm = true;trong trinity_dpm_init()trong src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.c, và biên dịch nó với makepkg --noextract. Sau đó, tôi đã cài đặt nó ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzvà pacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz) và cập nhật GRUB( grub-mkconfig -o /boot/grub/grub.cfgnhưng, tất nhiên, YMMV).

Kết quả là, tôi đã được lựa chọn để khởi động linuxhoặc linux-tc, và các thử nghiệm sau đây đề cập đến cái sau.

Trường hợp thử nghiệm 2.1: BIOS TC trên - CnQ on / Linux OnDemand - Boost

Thiết lập lõi Turbo của UEFI ............................ Đã bật
Cài đặt UEFI BIOS Cool'n'Quiet .......................... Đã bật
/ sys / thiết bị / hệ thống / cpu / cpufreq / boost ................... 1
/ sys / thiết bị / hệ thống / cpu / cpu * / cpufreq / scaling_gocateor ... ondemand 

"Thông tin tần số cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Phạm vi cpu MHz "/ Proc / cpuinfo" được quan sát ... 1800 - 3700
Phạm vi Freq "màn hình cpupower" được quan sát ... 1800 - 4300
/ sys / kernel / debug / Dri / 0 / radeon_pm_info ... mức năng lượng 0

Tải | Freq cốt lõi
--------------- + -----------------
căng thẳng - lõi 1 | 1 x 4300
căng thẳng --cpu 2 | 2 x 4200 .. 4100
căng thẳng - cpu 3 | 3 x 4100 .. 3900
căng thẳng - cpu 4 | 4 x 4000 .. 3800

Trường hợp thử nghiệm 2.2: BIOS TC trên - Hiệu suất CnQ trên / Linux - Tăng cường

Thiết lập lõi Turbo của UEFI ............................ Đã bật
Cài đặt UEFI BIOS Cool'n'Quiet .......................... Đã bật
/ sys / thiết bị / hệ thống / cpu / cpufreq / boost ................... 1
/ sys / thiết bị / hệ thống / cpu / cpu * / cpufreq / scaling_gocateor ... biểu diễn

"Thông tin tần số cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Phạm vi cpu MHz "/ Proc / cpuinfo" được quan sát ... 3700
Phạm vi Freq "màn hình cpupower" được quan sát ... 2000 - 4300
/ sys / kernel / debug / Dri / 0 / radeon_pm_info ... mức năng lượng 0

Tải | Freq cốt lõi
--------------- + -----------------
căng thẳng - lõi 1 | 1 x 4300
căng thẳng --cpu 2 | 2 x 4200 .. 4100
căng thẳng - cpu 3 | 3 x 4100 .. 3900
căng thẳng - cpu 4 | 4 x 4000 .. 3800

Trường hợp thử nghiệm 2.3: BIOS TC trên - CnQ on / Linux OnDemand - Không tăng

Thiết lập lõi Turbo của UEFI ............................ Đã bật
Cài đặt UEFI BIOS Cool'n'Quiet .......................... Đã bật
/ sys / thiết bị / hệ thống / cpu / cpufreq / boost ................... 0
/ sys / thiết bị / hệ thống / cpu / cpu * / cpufreq / scaling_gocateor ... ondemand

"Thông tin tần số cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Phạm vi cpu MHz "/ Proc / cpuinfo" được quan sát ... 1800 - 3700
Phạm vi Freq "màn hình cpupower" được quan sát ... 1800 - 3700
/ sys / kernel / debug / Dri / 0 / radeon_pm_info ... cấp độ 1

Tải | Freq cốt lõi
--------------- + -----------
căng thẳng - lõi 1 | 1 x 3700
căng thẳng --cpu 2 | 2 x 3700
căng thẳng - cpu 3 | 3 x 3700
căng thẳng - cpu 4 | 4 x 3700

Trường hợp thử nghiệm 2.4: BIOS TC trên - Hiệu suất CnQ trên / Linux - Không tăng

Thiết lập lõi Turbo của UEFI ............................ Đã bật
Cài đặt UEFI BIOS Cool'n'Quiet .......................... Đã bật
/ sys / thiết bị / hệ thống / cpu / cpufreq / boost ................... 0
/ sys / thiết bị / hệ thống / cpu / cpu * / cpufreq / scaling_gocateor ... biểu diễn

"Thông tin tần số cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Phạm vi cpu MHz "/ Proc / cpuinfo" được quan sát ... 3700
Phạm vi Freq "màn hình cpupower" được quan sát ... 2000 - 3700
/ sys / kernel / debug / Dri / 0 / radeon_pm_info ... cấp độ 1

Tải | Freq cốt lõi
--------------- + -----------
căng thẳng - lõi 1 | 1 x 3700
căng thẳng --cpu 2 | 2 x 3700
căng thẳng - cpu 3 | 3 x 3700
căng thẳng - cpu 4 | 4 x 3700

Trường hợp thử nghiệm 2.5: Tắt BIOS TC - CnQ bật / Linux OnDemand - Boost

Cài đặt lõi Turbo của UEFI ............................ Đã tắt
Cài đặt UEFI BIOS Cool'n'Quiet .......................... Đã bật
/ sys / thiết bị / hệ thống / cpu / cpufreq / boost ................... 1
/ sys / thiết bị / hệ thống / cpu / cpu * / cpufreq / scaling_gocateor ... ondemand 

"Thông tin tần số cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Phạm vi cpu MHz "/ Proc / cpuinfo" được quan sát ... 1800 - 3700
Phạm vi Freq "màn hình cpupower" được quan sát ... 1800 - 3700
/ sys / kernel / debug / Dri / 0 / radeon_pm_info ... mức năng lượng 0

Nói cách khác, nếu Turbo Core bị vô hiệu hóa trong BIOS, bản vá radeonsẽ không bật nó.

Trường hợp thử nghiệm 2.6: BIOS TC bật - CnQ tắt / Linux không áp dụng

Thiết lập lõi Turbo của UEFI ............................ Đã bật
Cài đặt UEFI BIOS Cool'n'Quiet .......................... Đã tắt
/ sys / thiết bị / hệ thống / cpu / cpufreq / boost ................... n / a
/ sys / thiết bị / hệ thống / cpu / cpu * / cpufreq / scaling_gocateor ... n / a

"Thông tin tần số cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Phạm vi cpu MHz "/ Proc / cpuinfo" được quan sát ... 3700
Phạm vi Freq "màn hình cpupower" được quan sát ... 2000 - 4300
/ sys / kernel / debug / Dri / 0 / radeon_pm_info ... mức năng lượng 0

Tải | Freq cốt lõi
--------------- + -----------------
căng thẳng - lõi 1 | 1 x 4300
căng thẳng --cpu 2 | 2 x 4100 .. 4000
căng thẳng - cpu 3 | 3 x 4000 .. 3800
căng thẳng - cpu 4 | 4 x 3900 .. 3700

Khi Cool'n'Qiet bị vô hiệu hóa, nhân Linux sẽ không đưa ra bất kỳ lựa chọn nào của thống đốc và (sai) cho rằng các lõi chạy ở tần số cố định. Thật thú vị, tần số Turbo Core kết quả là tồi tệ nhất trong tất cả các kết hợp được thử nghiệm trong Test Case Group 2.

Tóm tắt Test Case Nhóm 2

Với radeontrình điều khiển được vá , Turbo Core hoạt động. Không có sự bất ổn nào (đó là lý do tại sao bapmcòn gọi là Turbo Core bị vô hiệu hóa ở đó) cho đến nay.

Trường hợp thử nghiệm Nhóm 3: Linux + fglrx (chất xúc tác)

Tôi đã bắt đầu với bản cài đặt Ubuntu (14.04 Server, kernel 3.13) mới, mà tôi thấy tương đương với Arch Linux (trình cài đặt 2014.08.01, kernel 3.15.7) do sự hiện diện của acpi_cpufreq(nhân CPU CPU) và radeon(trình điều khiển GPU kernel ). Lý do để chuyển sang Ubuntu là cài đặt dễ dàng fglrx. Tôi xác nhận mức tiêu thụ năng lượng và hành vi với cài đặt mới, sử dụng radeon.

Tôi đã cài đặt fglrxtừ dòng lệnh ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) và khởi động lại hệ thống. Sự thay đổi từ radeonthành fglrxrõ ràng ngay lập tức cả về ngoại hình giao diện điều khiển ( fglrx: 128 x 48 , radeon: cao hơn nhiều) và mức tiêu thụ điện ở chế độ không tải ( fglrx: 40W , radeon: 30W). Nhưng Turbo Core hoạt động ngay lập tức.

Trường hợp thử nghiệm 3.1: BIOS TC trên - CnQ on / Linux OnDemand - Boost

Thiết lập lõi Turbo của UEFI ............................ Đã bật
Cài đặt UEFI BIOS Cool'n'Quiet .......................... Đã bật
/ sys / thiết bị / hệ thống / cpu / cpufreq / boost ................... 1
/ sys / thiết bị / hệ thống / cpu / cpu * / cpufreq / scaling_gocateor ... ondemand 

"Thông tin tần số cpupower" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Phạm vi cpu MHz "/ Proc / cpuinfo" được quan sát ... 1800 - 3700
Phạm vi Freq "màn hình cpupower" được quan sát ... 1800 - 4300
/ sys / kernel / debug / Dri / 0 / radeon_pm_info ... n / a

Tải | Freq cốt lõi
--------------- + ----------------------------
căng thẳng - lõi 1 | 1 x 4300
căng thẳng --cpu 2 | 2 x 4200 .. 3900 (lõi chg)
căng thẳng - cpu 3 | 3 x 4100 .. 3700
căng thẳng - cpu 4 | 4 x 4000 .. 3600

Các fglrxhành vi chắc chắn là thú vị. Khi 'stress --cpu 2' được gọi cho bất kỳ trường hợp tes nào trong bất kỳ nhóm trường hợp thử nghiệm nào, hai lõi được tải luôn nằm trên các mô-đun riêng biệt. Nhưng với fglrx, việc tái phân bổ đột ngột xảy ra sao cho một mô-đun duy nhất được sử dụng (giúp tiết kiệm khá nhiều năng lượng xem bên dưới). Sau một thời gian, lõi được tải chuyển trở lại mô-đun khác. Điều này đã không được nhìn thấy với radeon. Có thể đó là fglrxthao túng mối quan hệ cốt lõi của các quá trình?

Tóm tắt Test Case Nhóm 3

Ưu điểm của fglrxnó là cho phép Turbo Core ngay lập tức mà không cần phải vá nó.

Vì fglrxlãng phí 10 đến 12W cho GPU trong kịch bản của chúng tôi trên chip với TDP 65W, kết quả chung về tốc độ lõi khả dụng là không ấn tượng. Do đó, không có thử nghiệm nào được tiến hành.

Cũng theo quan điểm kỹ thuật, hành vi có fglrxvẻ hơi buồn. Việc tái phân bổ một trong hai lõi bận rộn cho mô-đun kia để duy trì tần số cao hơn có thể là một ý tưởng tốt, bởi vì trước bước đó, cả hai lõi đều có bộ đệm L2 của riêng chúng, trong khi sau đó, chúng phải chia sẻ một lõi. Việc fglrxxem xét bất kỳ số liệu nào (chẳng hạn như lỗi nhấn bộ nhớ cache) để hỗ trợ quyết định của nó sẽ phải được làm rõ riêng, nhưng có những báo cáo khác về hành vi đột ngột của nó .

Tóm tắt về tiêu thụ điện năng

Một số giá trị delta trong bảng sau trở nên tồi tệ hơn khi nhiệt độ tăng; người ta có thể nói quạt điều khiển PWM và chip đều đóng vai trò ở đó.

Hệ thống @State / -> Delta chuyển tiếp | Hệ thống tản điện
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86W
  @ Xe tải | @ 108 .. 89W
  @Ub cài đặt nhàn rỗi | @ 40W
  @Linux radeon nhàn rỗi | @ 30W
  @Linux radeon Hiệu suất nhàn rỗi | @ 30W
  @Linux fglrx nhàn rỗi | @ 40W
  1 Mô-đun 1800 -> 3700 | + 13W
  1 Mô-đun 1800 -> 4300 | + 25W
  1 lõi 1800 -> 3700 | + 5W
  1 lõi 1800 -> 4300 | + 10W
  Video "radeon" -> Tắt | - 2W
  'fglrx "Video Out -> Làm tối | + - 0W
  @Linux radeon Tối đa | @ 103 .. 89W
  @Linux fglrx Tối đa | @ 105 .. 92W

• Dường như có nhiều hơn với Turbo Core (ít nhất là với APU Richland) so với dự kiến: Không có sự khác biệt đáng chú ý nào về sự tiêu tán năng lượng khi có bộ điều chỉnh tỷ lệ "ondemand" so với khi có bộ điều chỉnh "hiệu suất". Althouth /proc/cpuinfosẽ luôn báo cáo 37000 MHz theo thống đốc hiệu suất, cpupower monitorsẽ tiết lộ rằng các lõi thực sự làm chậm. Trong một số trường hợp, tần số thấp đến 2000 MHz đã được hiển thị; có thể 1800 MHz bên trong cũng sẽ được sử dụng.
• A10-6700 bao gồm hai mô-đun với hai lõi mỗi lõi. Nếu ví dụ: hai lõi không hoạt động và hai lõi đang bận và được tăng tốc, thì hành vi hệ thống sẽ khác nhau tùy thuộc vào việc các lõi bận có nằm trên cùng một mô-đun hay không.
  • Tăng tốc một mô-đun tốn nhiều năng lượng hơn là tăng tốc lõi.
  • Bộ đệm L2 được gán cho mỗi mô-đun.
• Sự khác biệt giữa công suất tiêu tán của hai lõi tăng tốc trên cùng một mô-đun so với các mô-đun khác nhau được xác định bằng cách thay thế stress --cpu 2(điều này luôn dẫn đến sự phân phối giữa hai mô-đun) .taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• A10-6700 dường như có giới hạn tiêu thụ toàn bộ năng lượng cho APU (92W cùng với các thành phần khác) với một chút nhỏ chỉ dành riêng cho GPU (3 W). Với radeon, nó sẽ cho phép nhiều hơn trong một khoảng thời gian ngắn và giảm đến mức tối đa rất trơn tru, trong khi với fglrx, nó đã được quan sát thấy rằng các giới hạn này được vượt quá đáng kể và tiêu hao năng lượng sau đó giảm đột ngột.
• Trong khi nhiều người cho rằng sự chậm trễ trong tính khả dụng của Kaveri là do AMD dự định vì nó sẽ giết chết các APU hiện tại của họ, tôi xin hãy khác biệt. Richland A10 đã thể hiện khả năng quản lý năng lượng tuyệt vời và Kaveri không thể cạnh tranh với mức tiêu thụ năng lượng ở trạng thái nhàn rỗi thấp (độ phức tạp chip của Kaver gần gấp đôi so với Richland, do đó sẽ phải thực hiện thêm một hoặc hai bước phát triển).

Kết luận chung

• Bao gồm nhiệt độ trong logic Turbo Core (như được báo cáo cho bước Trinity -> Richland) dường như có ý nghĩa và dường như hoạt động tốt, có thể thấy bằng cách giảm sự phân tán pwoer trong BIOS và Bootloader theo thời gian.
• Đối với kịch bản cosole / máy chủ, A10-6700 hỗ trợ 4 lõi @ 3700 MHz (3800 MHz với Turbo Core) trong thời gian dài, ít nhất là với radeontrình điều khiển. Có lẽ không có nhiều cơ hội để duy trì mức hiệu suất này khi GPU có một số việc phải làm.
• Dường như TDP 65W có thể bị vượt quá vĩnh viễn một chút dưới mức đầy tải, nhưng thật khó để nói vì nguồn cung cấp có hiệu suất thấp hơn ở mức 30W. Vì có dấu hiệu rõ ràng rằng nhiệt độ được xem xét (mức tiêu thụ năng lượng cực đại gần 110W đã được quan sát trước khi nó bắt đầu giảm xuống 90W và cũng có 2 lõi ở 4300 MHz được báo cáo trong một thời gian), đầu tư vào làm mát APU có thể là một ý tưởng tốt. Tuy nhiên, các bo mạch chính giới hạn ở TDP 65W sẽ chỉ có thể cung cấp rất nhiều dòng điện, do đó chắc chắn sẽ có một giới hạn cứng do APU áp đặt.
• Nếu bạn có ý định sử dụng APU Richland để tính toán trong Linux, bạn chắc chắn muốn sử dụng radeontrình điều khiển được vá (nếu bạn không gặp phải sự bất ổn - đặc biệt là kết hợp với bật Quản lý năng lượng động). Nếu không, bạn sẽ không nhận được giá trị đầy đủ.
• Thật kỳ lạ, có vẻ như thiết lập tốt nhất sẽ là kích hoạt cả Turbo Core và Cool'n'Quiet trong BIOS nhưng sau đó chọn bộ performanceđiều chỉnh tỷ lệ - ít nhất là nếu APU của bạn hoạt động giống như thử nghiệm ở đây. Bạn sẽ có mức tiêu thụ năng lượng tương tự như với ondemandquy mô tần số nhanh hơn và chi phí nhân ít hơn để đưa ra quyết định mở rộng.

Sự nhìn nhận

Cảm ơn đặc biệt đến Alex Deucher, người đã đẩy tôi đi đúng hướng tại bugzilla.kernel.org .

Tôi ấn tượng bởi chất lượng của radeontrình điều khiển miễn phí và xin cảm ơn cả nhóm vì đã duy trì phần mềm này, có vẻ như được thiết kế chu đáo. Nếu radeonkhông hành xử như vậy, quyết định của tôi ủng hộ A10-6700 sẽ là sai lầm đáng kể.