☰

AMD A10-6700（Richland）APU体验

tag-icon • tag-icon cpu-frequency radeon fglrx amd turbo-core
AMD A10-6700（Richland）APU体验

我的目标是建立一个在空闲模式下具有低功耗但在使用时提供良好性能的迷你服务器（不是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 与英特尔酷睿 i3-3220：
    • A10-6700 具有更多的 GPU 能力，此处未使用。
    • i3-3220 具有较低的空闲模式功耗。
    • 虽然在典型的基准测试中，i3-3220 的计算速度更快，但我看不出它的两个超线程核心如何能够像四个全功能核心（至少当假设有一些严重的缓存时）。不过，没有找到任何严格的基准——只有一些迹象。

[编辑：自 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（Richland）APU体验

处理器选择

我的第一台 PC 是一台 486DX2-66，由数十张包含 Slackware 源代码包的 3.5 英寸软盘组成。现在，很多事情都发生了变化，目前许多行业似乎仍处于增加数量的阶段产品变体。

这种情况以及 AMD 最近做出的一些不幸的决定并没有让我更容易决定迷你服务器的平台。但最终，我认为 A10-6700 将是一个不错的选择：

  • 一些评论表明，Kaveri（仍然广泛不可用）在空闲模式下比 Richland 或 Trinity 消耗更多电量
  • Richland A10-6700 相对于 Trinity A10-5700 的优势似乎很明显：更低的最低频率和更高的最高频率、更细粒度的 Turbo Core（还考虑到温度——当 GPU 空闲时这是一个相当大的优势）
  • A10-6700 的 GPU 据说被高估了（营销驱动的命名），而 APU 的定价似乎很公平

其他组件和设置

尽管有无数的处理器可供选择，但可用的 Mini-ITX 主板并不多。华擎 FM2A78M-ITX+ 似乎是一个合理的选择。测试是使用固件 V1.30 完成的（在我撰写本文时没有可用的更新）。

仅消耗电源标称输出的 80%。另一方面，许多设备在负载低于 50% 时无法高效工作。为估计功耗范围为 35W 至 120W 的系统找到高效节能的电源非常困难。我使用海韵 G360 80+ Gold 进行了这些测试，因为它在低负载效率方面优于大多数竞争对手。

测试设置还包括两个 8GB DDR3-1866 RAM（这样配置，与 1333 相比确实有所不同）、一个 SSD 驱动器和一个 PWM 控制质量的 CPU 风扇。

测量是使用 AVM Fritz!DECT 200 进行的，据报道该设备可以执行准确的测量。尽管如此，还是使用旧的无名设备验证了其合理性。没有发现任何不一致之处。测量的系统功耗将包括电源因负载较低而降低的效率。

通过 HDMI 连接 [W]QHD 屏幕。

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 开启 - CnQ 开启 / Linux OnDemand - Boost

UEFI BIOS Turbo 核心设置.................................启用
UEFI BIOS Cool'n'Quiet 设置.................................启用
/sys/devices/system/cpu/cpufreq/boost............ 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 按需

“cpupower频率信息” 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×3700
压力--cpu 2 | 2×3700
压力--CPU 3 | 3×3700
压力--CPU 4 | 4×3700

测试案例 1.2：BIOS TC 开启 - CnQ 开启 / Linux 性能 - 提升

UEFI BIOS Turbo 核心设置.................................启用
UEFI BIOS Cool'n'Quiet 设置.................................启用
/sys/devices/system/cpu/cpufreq/boost............ 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 性能

“cpupower频率信息” 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×3700
压力--cpu 2 | 2×3700
压力--CPU 3 | 3×3700
压力--CPU 4 | 4×3700

测试用例组 1 摘要

在这种情况下，基于 Turbo Core 的增强是不可能的，因为由于某些情况下的稳定性问题，驱动radeon程序当前禁用了该标志bapm。因此，跳过了进一步的测试。

测试用例组 2：Linux + 打了 bapm 补丁的 radeon

为了启用bapm，我从一个新的 Arch Linux（安装程序 2014.08.01，内核 3.15.7）开始，core linux通过ABS(3.15.8) 获取软件包，编辑PKGBUILD要使用的pkgbase=linux-tc，使用 拉取源代码，在中makepkg --nobuild进行更改，然后编译它与.然后，我安装了它（和）并更新了（但是，当然，YMMV）。pi->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

结果我就选择了 bootlinux或者linux-tc，下面的测试都是指后者。

测试案例 2.1：BIOS TC 开启 - CnQ 开启 / Linux OnDemand - Boost

UEFI BIOS Turbo 核心设置.................................启用
UEFI BIOS Cool'n'Quiet 设置.................................启用
/sys/devices/system/cpu/cpufreq/boost............ 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 按需

“cpupower频率信息” 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×4300
压力--cpu 2 | 2×4200..4100
压力--CPU 3 | 3×4100..3900
压力--CPU 4 | 4×4000..3800

测试案例 2.2：BIOS TC 开启 - CnQ 开启 / Linux 性能 - 提升

UEFI BIOS Turbo 核心设置.................................启用
UEFI BIOS Cool'n'Quiet 设置.................................启用
/sys/devices/system/cpu/cpufreq/boost............ 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 性能

“cpupower频率信息” 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×4300
压力--cpu 2 | 2×4200..4100
压力--CPU 3 | 3×4100..3900
压力--CPU 4 | 4×4000..3800

测试案例 2.3：BIOS TC 开启 - CnQ 开启 / Linux OnDemand - 无升压

UEFI BIOS Turbo 核心设置.................................启用
UEFI BIOS Cool'n'Quiet 设置.................................启用
/sys/devices/system/cpu/cpufreq/boost............ 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 按需

“cpupower频率信息” 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×3700
压力--cpu 2 | 2×3700
压力--CPU 3 | 3×3700
压力--CPU 4 | 4×3700

测试案例 2.4：BIOS TC 开启 - CnQ 开启 / Linux 性能 - 无提升

UEFI BIOS Turbo 核心设置.................................启用
UEFI BIOS Cool'n'Quiet 设置.................................启用
/sys/devices/system/cpu/cpufreq/boost............ 0
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 性能

“cpupower频率信息” 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×3700
压力--cpu 2 | 2×3700
压力--CPU 3 | 3×3700
压力--CPU 4 | 4×3700

测试案例 2.5：BIOS TC 关闭 - CnQ 打开 / Linux OnDemand - Boost

UEFI BIOS Turbo 核心设置................................................禁用
UEFI BIOS Cool'n'Quiet 设置.................................启用
/sys/devices/system/cpu/cpufreq/boost............ 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 按需

“cpupower频率信息” 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 Turbo 核心设置.................................启用
UEFI BIOS Cool'n'Quiet 设置.................................禁用
/sys/devices/system/cpu/cpufreq/boost........... 不适用
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 不适用

“cpupower频率信息” 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×4300
压力--CPU 2 | 2×4100..4000
压力--CPU 3 | 3×4000..3800
压力--CPU 4 | 4×3900..3700

禁用 Cool'n'Qiet 后，Linux 内核将不会提供任何调节器选择，并且（错误地）假设内核以固定频率运行。有趣的是，生成的 Turbo Core 频率是测试用例组 2 中所有测试组合中最差的。

测试用例组 2 摘要

使用修补后的radeon驱动程序，Turbo Core 可以工作。bapm到目前为止，还没有发现任何不稳定性（这就是为什么又名 Turbo Core 被禁用的原因）。

测试用例组 3：Linux + fglrx（催化剂）

我从全新的 Ubuntu（14.04 Server，内核 3.13）安装开始，我认为它与 Arch Linux（安装程序 2014.08.01，内核 3.15.7）相当，因为存在acpi_cpufreq（内核 CPU 扩展）和radeon（内核 GPU 驱动程序） ）。切换到 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 - Boost

UEFI BIOS Turbo 核心设置.................................启用
UEFI BIOS Cool'n'Quiet 设置.................................启用
/sys/devices/system/cpu/cpufreq/boost............ 1
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor... 按需

“cpupower频率信息” 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 | 1×4300
压力--CPU 2 | 2 x 4200 .. 3900（核心更改）
压力--CPU 3 | 3×4100..3700
压力--CPU 4 | 4×4000..3600

这种fglrx行为绝对很有趣。当对任何测试用例组中的任何 tes 用例调用“stress --cpu 2”时，两个加载的核心始终位于单独的模块上。但是使用 时fglrx，突然发生重新分配，从而使用单个模块（这节省了相当多的电量，请参见下文）。一段时间后，加载的核心移回另一个模块。这是没有看到的radeon。是否可以fglrx操纵进程的核心亲和力？

测试用例组 3 摘要

优点fglrx是它可以立即启用 Turbo Core，无需任何修补。

fglrx由于在我们的场景中，在 TDP 为 65W 的芯片上，GPU 浪费了 10 到 12W 的功率，因此关于可用核心速度的总体结果并不令人印象深刻。因此，没有进行进一步的测试。

同样从工程学的角度来看， 的行为fglrx显得有点可悲。将两个繁忙的核心之一重新分配给另一个模块以保持较高的频率可能是也可能不是一个好主意，因为在这一步之前，两个核心都有自己的二级缓存，而之后，它们必须共享一个。无论fglrx考虑任何指标（例如缓存命中未命中）来支持其决策必须单独澄清，但是还有其他关于其突然行为的报道。

功耗汇总

随着温度升高，下表中的一些增量值会稍微变差；有人可能会说 PWM 控制的风扇和芯片都在那里发挥作用。

系统@State / ->转换增量|系统功耗
----------------------------------+------------------------ -------------
  @BIOS | @95..86W
  @Bootloader | @108..89W
  @Ubuntu 安装程序空闲 | @40W
  @Linux radeon 空闲点播 | @30W
  @Linux radeon 空闲性能 | @30W
  @Linux fglrx 空闲点播 | @40W
  1 模块 1800 -> 3700 | +13W
  1 模块 1800 -> 4300 | +25W
  1 核心 1800 -> 3700 | + 5W
  1 核 1800 -> 4300 | +10W
  “radeon”视频输出 -> 禁用 | - 2W
  'fglrx" 视频输出 -> 变暗 | +- 0W
  @Linux radeon 最大 | @103..89W
  @Linux fglrx 最大 | @105..92W
  • Turbo Core（至少对于 Richland APU）似乎比预期的要多：与“性能”调节器就位相比，“按需”缩放调节器就位时功耗没有明显差异。尽管/proc/cpuinfo在性能调速器下总是会报告 37000MHz，但cpupower monitor会显示内核实际上确实变慢了。在某些情况下，显示的频率低至 2000MHz；内部也可能使用 1800MHz。
  • A10-6700 由两个模块组成，每个模块有两个内核。例如，如果两个核心空闲，而两个核心忙碌并加速，则系统行为将根据忙碌核心是否位于同一模块上而有所不同。
    • 加速模块比加速核心更耗能。
    • L2 缓存按模块分配。
  • 在同一模块上加速的两个内核与在不同模块上加速的两个内核的功耗之间的差异通过将 替换stress --cpu 2（这总是导致两个模块之间的分布）来确定。taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
  • A10-6700 似乎对 APU 具有总功耗限制（连同其他组件为 92W），仅为 GPU 保留了一小部分（3W）。使用 时radeon，它将在短时间内允许更多，并非常平稳地减少到最大值，而使用 时fglrx，我们观察到这些限制被更显着地超出，然后功耗突然降低。
  • 虽然许多人声称延迟 Kaveri 的可用性是 AMD 有意为之的，因为这会毁掉他们当前的 APU，但我不敢苟同。 Richland A10已经展示了出色的电源管理，而Kaveri无法与其低空闲状态功耗竞争（Kaveri的芯片复杂度几乎是Richland的两倍，因此还需要再进行一到两个开发步骤）。

总体结论

  • 在 Turbo Core 逻辑中包含温度（如 Trinity -> Richland 步骤所报告的那样）似乎很有意义，并且效果良好，这可以从 BIOS 和 Bootloader 中功率耗散随着时间的推移而减少看出。
  • 对于控制台/服务器场景，A10-6700 长期支持 4 核 @ 3700MHz（Turbo Core 为 3800MHz），至少在radeon驱动程序方面是这样。当 GPU 需要完成一些工作时，可能没有太多机会保持这种性能水平。
  • 满载情况下似乎可以永久略微超过 65W TDP，但这很难说，因为电源在 30W 时效率较低。由于有明确的迹象表明考虑了温度（在开始降低至 90W 之前观察到了近 110W 的峰值功耗，并且一段时间内报告了 2 个 4300 MHz 的核心），因此投资 APU 冷却可能是一个明智的选择。好主意。然而，TDP 限制为 65W 的主板只能提供这么多电流，因此 APU 肯定会受到硬性限制。
  • 如果您打算在 Linux 下使用 Richland APU 进行计算，您肯定需要使用修补过的radeon驱动程序（如果您没有遇到不稳定问题——特别是在启用动态电源管理时）。否则，您将无法获得全部价值。
  • 奇怪的是，似乎最好的设置是在 BIOS 中启用 Turbo Core 和 Cool'n'Quiet，然后选择缩放performance调速器 - 至少如果您的 APU 的行为与此处测试的 APU 类似的话。您将拥有与使用相同的功耗，ondemand但做出扩展决策时的频率缩放速度更快，内核开销更少。

致谢

特别感谢 Alex Deucher，他对把我推向正确的方向 bugzilla.kernel.org。

免费驱动程序的质量给我留下了深刻的印象radeon，并感谢整个团队维护这个软件，它似乎是经过深思熟虑的设计的。如果radeon不这样做，我选择 A10-6700 的决定就大错特错了。

相关内容