是否最好禁用 APM,或启用负载线校准以实现超频稳定性?

是否最好禁用 APM,或启用负载线校准以实现超频稳定性?

AMD FX 系列处理器与 9 系列芯片组配对,主板提供了禁用 APM(应用程序电源管理)的选项。大多数超频指南建议禁用 APM 以获得更好的稳定性至少在最初阶段是这样。其中包括官方AMD FX 性能调优指南,第 5 页和第 10 页。第 5 页指出:

由于 APM 设置了预定义的 TDP 限制,因此通常建议禁用AMD Turbo Core 技术以及加速计划当将 CPU 频率和电压提高到默认水平以上时,此功能将启用。

Ron 的技术提示还有这样的话:

简而言之,AMD 应用程序电源管理 BIOS 设置可确保 CPU 保持在芯片设计的 125W(8 核)或 95W(4 核和 6 核)TDP 范围内。我见过很多人说 APM 会导致 CPU 节流,这既是真的也是假的。确实,有时 APM 会导致这种情况,但节流并不总是如此。有时它会稍微降低电压,同时保持 CPU 处于较高的时钟频率

所有的重点都是我的。

此外,如今大多数发烧级主板还提供一项称为负载线校准 (LLC) 的功能。根据一位用户在Linus Tech Tips 论坛

Vdroop 是指随着负载增加而提供给 CPU 的电压下降;基本上,当您从空闲状态转为负载状态时,电压会降低。考虑到超频者使用的电压容差很小(增加的电压与超频可以实现的 CPU 频率/倍频成正比),施加到 CPU 的电压下降会使理论上稳定的超频变得不稳定(电压低于实现设定频率所需的电压)

以下是没有 LLC 时定义的 (X) 和测量的 (Y) vcore 值之间的差异:

LLC 常规 0%

请注意,实际的 vcore 值总是低于我们的预期。

在下图中,我们可以看到,对于特定的 CPU(i7 3930K)和 MoBo(Asus Rampage IV Extreme),LLC 设置为“高”(即值为 50%)足以补偿 vdroop:

LLC 高 50%

总结

我想知道的是,是禁用 APM 更好,(很可能)使用较低的 LLC 级别(有时根本不需要),还是保持 APM 启用,并不得不采用更高的 LLC 设置来保持一切稳定。我的顾虑如下:

  • 系统稳定性
  • 计算完整性
  • 系统耐用性(不太重要)
  • 热量输出和功耗(更不重要)

/TL;DR

(附加信息)
之所以问这个问题是因为更高的 LLC 设置会给 CPU 核心引入短暂的电压尖峰,正如这个问题中已经提到的:<使用偏移量或手动设置 CPU 电压(相对于 CPU 寿命)是否更好?>,以及在这个主人的巢穴. 引述:

如果您有一块不错的主板,负载线校准实际上不会为您带来任何更高的超频效果 (...)。它只会人为地降低您必须在 BIOS 中设置的 vcore,但 CPU 在负载下仍需要相同数量的电压。

我建议保持 [LLC] 禁用,除非您认为很难实现想要的超频,并且怀疑问题出在过多的 vdroop 上。

一方面,我怀疑 APM 的作用不只是“强制”整体 TDP 上限,因此尽管有相反的建议,但如果可能,还是应该保持启用状态。但另一方面,APM 似乎也会带来不稳定性,因此需要更高的 LLC 设置,这本身可能更糟。

为了完整性:

- CPU: FX-6350 @ 4.8 GHz (default is 3.9)
- Motherboard: Asus Sabertooth 990FX R2.0
- Turbo Core: Off
- CPU Offset Voltage: +0.09375v
- APM Master Mode: On
- C1E, C6 State, Cool'n'Quiet: All enabled (On)
- CPU Load Line Calibration: Ultra High (75%)
- CPU Power Phase Control: Standard
- CPU Power Duty Control: C.Probe (Current)
- Spread Spectrum is Off for CPU, CPU-NB and VRM.

笔记:

  • 我之前以 LLC High (50%) 运行此时钟速度,但经过 4 小时 30 分钟的测试后,Prime95 中出现计算错误,即使有 100mv (+0.1) vcore 偏移。

  • 然后我将偏移量降低了 6.25mv,并将 LLC 更改为超高,错误就消失了。

  • 然而,这会使负载电压平均上升 20mv,并且在某些负载转换期间会出现 12mv 的峰值(导致 1.488v),这比理想值略高。

  • 经过一天中数小时的数字运算,CPU 温度最高达到 63ºC。这是一个风冷系统(不过 Hyper 212X 的冷却器还算不错),在 -85mv 偏移(欠压)的情况下运行良好达 2 年之久

  • 我希望它至少能继续工作一年。

答案1

TL;WR

  • APM 不会影响稳定性,至少对于我的设置来说是这样
  • 然而,LLC 确实如此 - 事实上,就我而言,为了实现稳定、无错误的超频,它是绝对必要的。(而且有趣的是,它几乎总是允许您根本不配置任何偏移电压)。
  • APM 会影响性能。不过,通常最好将其启用,因为这样您可以配置更高的时钟速度,从而将带来更高的整体系统性能,特别适用于轻线程工作负载。它还可以节省电量。

    它是这样工作的:

    由 APM 控制的动画自动降频

    (使用 6 个工作线程进行 Prime95 小型 FFT 测试期间捕获)(24K FFT 大小)


详尽阐述

仍然根据Ron 的技术提示

禁用 APM 只会让您的 CPU 超出 125w TDP 范围。实际上,您会消耗更多功率和电压,并产生更多热量,但好处却微乎其微。(...)

我建议禁用 APM(应用程序电源管理)(...) 的唯一时间和情况是如果您有以下情况:

  1. 对于计划在 4.9 到 5GHz 范围内进行高超频(无论如何都会超出 TDP 限制)的 CPU,这是一种非常好的高端液体冷却解决方案。
    (...)

这里没有任何内容表明 APM 对系统稳定性有任何影响,尽管前面的引述(来自问题)似乎表明如此(“有时它会稍微降低电压,同时保持 CPU 处于较高的时钟频率”)。

因此,我针对以下场景进行了测试:

  • 4800 MHz @ 0.09375v 偏移;LLC [超高];APM [已启用]
  • 同上,APM [已禁用]

并观察到:

  1. APM 对系统稳定性没有任何影响
  2. CPU 性能提升 3.27%,在 Passmark 性能测试中达到 9132 分。这一分数高于FX-8370passmark cpu 性能结果 最为显着地:
    • 浮点性能提升8.14%
    • SSE性能提升8.93%(SSE以FP方式实现)
    • 素数计算也快 10%
    • 整数性能不变

然而,好人有好报,坏人也有坏报,因此代价也很大:Prime95 满载情况下 15-20 分钟内温度就达到 73ºC。这几乎增加了 16% 的热量,比 CPU 热容高出 3ºC。显然,使用空气冷却无法维持。

然后我测试了以下场景:

  • 4700 MHz @ 库存电压(无偏移);LLC [超高];APM [已启用]
  • 4500 MHz @ 相同(无电压偏移和 LLC Ultra),带 APM [已禁用]

结果是:

  1. 两者都同样非常稳定
  2. 对于 4500 MHz,电压固定为 1.44v,对于使用 APM 的 4700 MHz,电压平均约为 1.428v
  3. 满载情况下,4500 MHz 的功耗为 ~266.6 VA,4700 MHz+APM 的功耗为 ~239.9 VA(用钳形表测量;实际功耗(瓦特)会略低)
  4. 空闲时的功率分别为 62.1 VA 和 64.7 VA
  5. 4500 MHZ 的最大温度为 65ºC(插座)、61.1ºC(Tcl)和 75ºC(VRM);4700 MHz+APM 的最大温度为 57ºC(插座)、52.1ºC(Tcl)、68ºC(VRM)。
  6. 在 4700MHz 设置下,使用 Windows 10 64 位和 Arch Linux 上的 MinGW 编译大型项目的速度提高了约 3.8%
  7. 在 W10 上使用 Visual Studio 进行编译,并使用 Handbrake 转换 2 分钟 1080p 视频,速度提升 1.5%,达到 4700MHz
  8. Passmark 2D 图形性能在 4700 MHz 时快 2.78%
  9. 采用“基本”预设的 Unigine Heaven 基准测试平均快约 3.5%,最低 FPS 快 6.84%,频率为 4700 MHz
  10. 我有点惊讶,在启用 APM 的情况下,使用 Handbrake 进行转码的速度在 4700 MHz 时也更快,尽管此配置的浮点​​性能较低,因为编码是一项 FP 密集型任务。最可能的解释是测试持续时间太短(6 分 16 秒),不会导致 CPU 明显节流。因此,我尝试在“队列”中转换同一视频两次,总测试持续时间为 13 分 03 秒。切换到没有 APM 的 4500 MHz 后,速度下降到 12 分 44 秒,速度提高了 2.49%。

    这是我成功重现的唯一一个“真实世界”场景,其中较低时钟、禁用 APM 的配置确实更快。
    现在,这会带来 10% 以上的功耗(和更高的热量),这使得它对于除最专业的 FP 密集型应用程序之外的所有应用程序来说都不是理想的选择。

相关内容