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은 일반적인 벤치마크에서 더 빠르게 계산하지만 두 개의 하이퍼 스레드 코어가 어떻게 4개의 모든 기능을 갖춘 코어처럼 작동할 수 있는지 알 수 없습니다(적어도 심각한 캐싱을 가정할 때). 그러나 확실한 벤치마크는 발견되지 않았으며 단지 몇 가지 징후만 발견되었습니다.

[편집: Linux 3.16부터 무료 라데온 드라이버의 매개변수는 bapmKaveri, Kabini 및 데스크톱 Trinity, Richland 시스템에 대해 기본적으로 설정됩니다.]

그러나 3.16 기반 데비안에서는 부팅 매개변수가 작동하는 반면 기본값은 (아직?) 작동하지 않는 것 같습니다. 바라보다최대 에너지 및 컴퓨팅 효율성을 위해 AMD Turbo Core APU가 있는 Debian 시스템(2D 중심 또는 콘솔/서버)을 설정하는 방법은 무엇입니까?

[편집: 무료 라데온 드라이버에는 곧 bapm매개변수가 있을 예정입니다.]

결론은 radeonAPU에서 무료 드라이버의 패치 버전을 사용하여 Turbo Core를 지원하고 가능하다면 이를 최대한 활용하는 것(3D 그래픽 제외)이기 때문에(활성화하면 bapm일부 구성에서 불안정해질 수 있음) 이것이 좋습니다. 소식라데온의 향후 버전에는 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개의 8GB 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 켜짐 - 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전력 주파수 정보" 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×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전력 주파수 정보" 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×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 켜짐 - 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전력 주파수 정보" 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×4300 |
압력--cpu 2 | 2×4200..4100
압력--CPU 3 | 3×4100..3900
압력--CPU 4 | 4×4000..3800

테스트 사례 2.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전력 주파수 정보" 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×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전력 주파수 정보" 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×3700 |
압력--cpu 2 |
압력--CPU 3×3700 |
압력--CPU 4×3700 |

테스트 사례 2.4: BIOS TC 켜짐 - CnQ 켜짐 / Linux 성능 - 개선 없음

UEFI BIOS 터보 코어 설정................................................활성화됨
UEFI BIOS Cool'n'Quiet 설정........................................활성화됨
/sys/devices/system/cpu/cpufreq/boost........... 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 성능

"cpu전력 주파수 정보" 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×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전력 주파수 정보" 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이를 활성화하지 않습니다.

테스트 사례 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전력 주파수 정보" 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×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 켜짐 - 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전력 주파수 정보" 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... 해당 사항 없음

로드 중 |
---------------+---------------
압력--CPU 1×4300 |
스트레스--CPU 2 | 2 x 4200 .. 3900(코어 변경)
압력--CPU 3 | 3×4100..3700
압력--CPU 4 | 4×4000..3600

이 fglrx행동은 확실히 흥미롭습니다. 테스트 케이스 그룹의 테스트 케이스에서 "stress --cpu 2"가 호출되면 로드된 두 개의 코어는 항상 별도의 모듈에 있습니다. 그러나 사용하면 fglrx갑자기 재할당이 발생하여 단일 모듈이 사용됩니다(이로 인해 상당한 전력이 절약됩니다. 아래 참조). 일정 시간이 지나면 로드된 코어가 다른 모듈로 다시 이동됩니다. 이것은 보이지 않습니다 radeon. fglrx프로세스의 핵심 친화력을 조작하는 것이 가능합니까 ?

테스트 케이스 그룹 3 요약

장점 fglrx은 패치 없이 즉시 Turbo Core를 사용할 수 있다는 것입니다.

fglrx우리 시나리오에서는 TDP가 65W인 칩에서 GPU가 10~12W의 전력을 낭비하므로 사용 가능한 코어 속도에 관한 전반적인 결과는 인상적이지 않습니다. 따라서 더 이상의 테스트는 수행되지 않았습니다.

또한 엔지니어링 관점에서 볼 때 이러한 동작은 fglrx약간 한심해 보입니다. 주파수를 더 높게 유지하기 위해 두 개의 사용 중인 코어 중 하나를 다른 모듈에 재할당하는 것은 좋은 생각일 수도 있고 좋지 않을 수도 있습니다. 왜냐하면 이 단계 전에 두 코어 모두 자체 L2 캐시를 갖고 그 후에는 하나를 공유해야 하기 때문입니다. 그러나 fglrx결정을 뒷받침하는 것으로 간주되는 측정항목(예: 캐시 적중 실패)은 별도로 명시해야 합니다.갑작스러운 행동에 대한 다른 보고도 있었습니다.

전력 소비 요약

아래 표의 일부 델타 값은 온도가 증가함에 따라 약간 더 나빠집니다. PWM 제어 팬과 칩이 모두 거기에서 작동한다고 주장할 수 있습니다.

System@State/->변환 증가|시스템 전력 소비
---------+--------------- --- ----------
  @BIOS | @95..86W
  @부트로더 @108..89W
  @Ubuntu 설치 프로그램 유휴 @40W |
  @Linux 라데온 유휴 온디맨드 @30W |
  @Linux 라데온 유휴 성능 @30W |
  @Linux fglrx 유휴 온디맨드 @40W |
  1개 모듈 1800 -> 3700 |
  1개 모듈 1800 -> 4300 |
  1코어 1800 -> 3700 |
  1코어 1800 -> 4300 |
  "radeon" 비디오 출력 -> 비활성화됨 - 2W |
  'fglrx' 비디오 출력->어두움 | +- 0W
  @리눅스 라데온 맥스 @103..89W |
  @Linux fglrx 최대 @105..92W |

Turbo Core는 (적어도 Richland APU의 경우) 예상보다 더 많은 기능을 수행하는 것으로 보입니다. "Performance" 거버너를 사용하는 것과 "On Demand" 스케일링 거버너를 사용하는 경우 전력 소비에 눈에 띄는 차이가 없습니다. /proc/cpuinfo성능 거버너에서는 항상 37000MHz가 보고되지만 이는 cpupower monitor실제로 코어가 느려지고 있음을 보여줍니다. 어떤 경우에는 2000MHz만큼 낮은 주파수가 표시되며 1800MHz도 내부적으로 사용될 수 있습니다.
A10-6700은 각각 2개의 코어가 있는 2개의 모듈로 구성됩니다. 예를 들어 두 개의 코어가 유휴 상태이고 두 개의 코어가 사용 중이고 속도가 빨라지는 경우 사용 중인 코어가 동일한 모듈에 있는지 여부에 따라 시스템 동작이 달라집니다.
- 가속 모듈은 가속 코어보다 더 많은 에너지를 소비합니다.
- L2 캐시는 모듈별로 할당됩니다.
동일한 모듈에서 가속된 두 코어의 전력 소비와 서로 다른 모듈에서 가속된 두 코어의 전력 소비 차이는 stress --cpu 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의 칩보다 거의 두 배 더 복잡하므로 한두 가지 개발 단계가 더 필요합니다).

종합적인 결론

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은 일반적인 벤치마크에서 더 빠르게 계산하지만 두 개의 하이퍼 스레드 코어가 어떻게 4개의 모든 기능을 갖춘 코어처럼 작동할 수 있는지 알 수 없습니다(적어도 심각한 캐싱을 가정할 때). 그러나 확실한 벤치마크는 발견되지 않았으며 단지 몇 가지 징후만 발견되었습니다.

[편집: Linux 3.16부터 무료 라데온 드라이버의 매개변수는 bapmKaveri, Kabini 및 데스크톱 Trinity, Richland 시스템에 대해 기본적으로 설정됩니다.]

바라보다[풀] radeon drm-fixes-3.16.

그러나 3.16 기반 데비안에서는 부팅 매개변수가 작동하는 반면 기본값은 (아직?) 작동하지 않는 것 같습니다. 바라보다최대 에너지 및 컴퓨팅 효율성을 위해 AMD Turbo Core APU가 있는 Debian 시스템(2D 중심 또는 콘솔/서버)을 설정하는 방법은 무엇입니까?

[편집: 무료 라데온 드라이버에는 곧 bapm매개변수가 있을 예정입니다.]

결론은 radeonAPU에서 무료 드라이버의 패치 버전을 사용하여 Turbo Core를 지원하고 가능하다면 이를 최대한 활용하는 것(3D 그래픽 제외)이기 때문에(활성화하면 bapm일부 구성에서 불안정해질 수 있음) 이것이 좋습니다. 소식라데온의 향후 버전에는 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개의 8GB 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 켜짐 - 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전력 주파수 정보" 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×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전력 주파수 정보" 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×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 켜짐 - 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전력 주파수 정보" 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×4300 |
압력--cpu 2 | 2×4200..4100
압력--CPU 3 | 3×4100..3900
압력--CPU 4 | 4×4000..3800

테스트 사례 2.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전력 주파수 정보" 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×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전력 주파수 정보" 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×3700 |
압력--cpu 2 |
압력--CPU 3×3700 |
압력--CPU 4×3700 |

테스트 사례 2.4: BIOS TC 켜짐 - CnQ 켜짐 / Linux 성능 - 개선 없음

UEFI BIOS 터보 코어 설정................................................활성화됨
UEFI BIOS Cool'n'Quiet 설정........................................활성화됨
/sys/devices/system/cpu/cpufreq/boost........... 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 성능

"cpu전력 주파수 정보" 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×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전력 주파수 정보" 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이를 활성화하지 않습니다.

테스트 사례 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전력 주파수 정보" 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×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 켜짐 - 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전력 주파수 정보" 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... 해당 사항 없음

로드 중 |
---------------+---------------
압력--CPU 1×4300 |
스트레스--CPU 2 | 2 x 4200 .. 3900(코어 변경)
압력--CPU 3 | 3×4100..3700
압력--CPU 4 | 4×4000..3600

이 fglrx행동은 확실히 흥미롭습니다. 테스트 케이스 그룹의 테스트 케이스에서 "stress --cpu 2"가 호출되면 로드된 두 개의 코어는 항상 별도의 모듈에 있습니다. 그러나 사용하면 fglrx갑자기 재할당이 발생하여 단일 모듈이 사용됩니다(이로 인해 상당한 전력이 절약됩니다. 아래 참조). 일정 시간이 지나면 로드된 코어가 다른 모듈로 다시 이동됩니다. 이것은 보이지 않습니다 radeon. fglrx프로세스의 핵심 친화력을 조작하는 것이 가능합니까 ?

테스트 케이스 그룹 3 요약

장점 fglrx은 패치 없이 즉시 Turbo Core를 사용할 수 있다는 것입니다.

fglrx우리 시나리오에서는 TDP가 65W인 칩에서 GPU가 10~12W의 전력을 낭비하므로 사용 가능한 코어 속도에 관한 전반적인 결과는 인상적이지 않습니다. 따라서 더 이상의 테스트는 수행되지 않았습니다.

또한 엔지니어링 관점에서 볼 때 이러한 동작은 fglrx약간 한심해 보입니다. 주파수를 더 높게 유지하기 위해 두 개의 사용 중인 코어 중 하나를 다른 모듈에 재할당하는 것은 좋은 생각일 수도 있고 좋지 않을 수도 있습니다. 왜냐하면 이 단계 전에 두 코어 모두 자체 L2 캐시를 갖고 그 후에는 하나를 공유해야 하기 때문입니다. 그러나 fglrx결정을 뒷받침하는 것으로 간주되는 측정항목(예: 캐시 적중 실패)은 별도로 명시해야 합니다.갑작스러운 행동에 대한 다른 보고도 있었습니다.

전력 소비 요약

아래 표의 일부 델타 값은 온도가 증가함에 따라 약간 더 나빠집니다. PWM 제어 팬과 칩이 모두 거기에서 작동한다고 주장할 수 있습니다.

System@State/->변환 증가|시스템 전력 소비
---------+--------------- --- ----------
  @BIOS | @95..86W
  @부트로더 @108..89W
  @Ubuntu 설치 프로그램 유휴 @40W |
  @Linux 라데온 유휴 온디맨드 @30W |
  @Linux 라데온 유휴 성능 @30W |
  @Linux fglrx 유휴 온디맨드 @40W |
  1개 모듈 1800 -> 3700 |
  1개 모듈 1800 -> 4300 |
  1코어 1800 -> 3700 |
  1코어 1800 -> 4300 |
  "radeon" 비디오 출력 -> 비활성화됨 - 2W |
  'fglrx' 비디오 출력->어두움 | +- 0W
  @리눅스 라데온 맥스 @103..89W |
  @Linux fglrx 최대 @105..92W |

Turbo Core는 (적어도 Richland APU의 경우) 예상보다 더 많은 기능을 수행하는 것으로 보입니다. "Performance" 거버너를 사용하는 것과 "On Demand" 스케일링 거버너를 사용하는 경우 전력 소비에 눈에 띄는 차이가 없습니다. /proc/cpuinfo성능 거버너에서는 항상 37000MHz가 보고되지만 이는 cpupower monitor실제로 코어가 느려지고 있음을 보여줍니다. 어떤 경우에는 2000MHz만큼 낮은 주파수가 표시되며 1800MHz도 내부적으로 사용될 수 있습니다.
A10-6700은 각각 2개의 코어가 있는 2개의 모듈로 구성됩니다. 예를 들어 두 개의 코어가 유휴 상태이고 두 개의 코어가 사용 중이고 속도가 빨라지는 경우 사용 중인 코어가 동일한 모듈에 있는지 여부에 따라 시스템 동작이 달라집니다.
- 가속 모듈은 가속 코어보다 더 많은 에너지를 소비합니다.
- L2 캐시는 모듈별로 할당됩니다.
동일한 모듈에서 가속된 두 코어의 전력 소비와 서로 다른 모듈에서 가속된 두 코어의 전력 소비 차이는 stress --cpu 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의 칩보다 거의 두 배 더 복잡하므로 한두 가지 개발 단계가 더 필요합니다).

종합적인 결론

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 켜짐 - CnQ 켜짐 / Linux OnDemand - 부스트

테스트 사례 1.2: BIOS TC 활성화 - CnQ 활성화 / Linux 성능 - 개선

테스트 케이스 그룹 1 요약

테스트 사례 그룹 2: Bapm 패치가 포함된 Linux + radeon

테스트 사례 2.1: BIOS TC 켜짐 - CnQ 켜짐 / Linux OnDemand - 부스트

테스트 사례 2.2: BIOS TC 켜짐 - CnQ 켜짐 / Linux 성능 - 개선됨

테스트 사례 2.3: BIOS TC On - CnQ On/Linux OnDemand - 부스트 없음

테스트 사례 2.4: BIOS TC 켜짐 - CnQ 켜짐 / Linux 성능 - 개선 없음

테스트 사례 2.5: BIOS TC 끄기 - CnQ 켜기/Linux OnDemand - 부스트

테스트 사례 2.6: BIOS TC 켜기 - CnQ 끄기 / Linux 해당 없음

테스트 케이스 그룹 2 요약

테스트 사례 그룹 3: Linux + fglrx(Catalyst)

테스트 사례 3.1: BIOS TC 켜짐 - CnQ 켜짐 / Linux OnDemand - 부스트

테스트 케이스 그룹 3 요약

전력 소비 요약

종합적인 결론

감사의 말

관련 정보