笔记：这个问题与之前的一个问题重复，之前的问题已经得到了非常详细的答案。
2023 年夏天，我发表了一篇迟来的本主题摘要在我雇主的网站上。
=========
亲爱的超级用户们，
您可能还记得我前段时间提出的一个不太恰当的广泛问题……这是后续问题。这次我有足够的数据来更具体。在现场抓到一个罪魁祸首，这次我们有所准备。但是，第一个结果让我感到困惑。它不是 EIST，不是 PROCHOT，也不是 CLOCKMOD。今天之后，我想知道：“Windows 知道什么而我不知道”？我一定错过了一些甜蜜的秘密——另一个 MSR 或时钟控制机制……
问题：在几十台运行 Windows Server 2012 R2 的 PC 上，“时不时”会随机出现某台机器“像糖浆一样流淌”的情况。CPU 变得非常慢。2012 版的 Windows 任务管理器报告 CPU 时钟频率稳定在“0.22 GHz”，这是一个奇怪的值。电源循环后，问题消失。
到目前为止，有效平均 MTTF 约为 20 年，即不可能在实验室中重现。机器运行时温度很低，远离热节流阈值。通过生成几天的 100% CPU 负载并记录核心温度传感器来验证。在生产中，机器实际上几乎闲置了几个月 - 通过事件日志中的一些相关信息验证，表明 CPU 已经处于最低 EIST 时钟又一天 - 连续 100 多天，直到电源循环。没有本地环境因素或其他情况可以将此行为与关联起来。
CPU 是 Haswell Core i7 Core i7-4650U：双核带 HT，15W TDP，实际闲置时功耗可能小于 5W。名义上是“移动”CPU - 虽然机器不是笔记本电脑，但没有电池。确实有一个嵌入式控制器。
CPU 的标称时钟频率（印在锡上的频率）为 1.7 GHz。EIST 最大值为 2.3 GHz。Turbo 可以将单核频率提升至 3.3 GHz，所有核心频率提升至 2.9 GHz。参考时钟似乎是来自板载时钟合成器的 100 MHz（实际上似乎更像 98 MHz）。在正常情况下，在 Windows 或 Linux 中，在典型工作负载 = 空闲时，CPU 频率保持在 800 MHz（报告为 790 MHz），即乘数 = 8。
现在来看看 0.22 GHz。这是一个单一值，是所有四个核心的平均值。此外，它不是物理时钟速率 - 相反，它是由 Windows 从一些标称时钟速率和一些硬件“性能仪表”（可能是 MSR 寄存器）推断出来的，其中该值应该是最大性能的百分比。
Effective clock = Nominal max clock * "frequency percentage gage" * "throttling percentage gage"
或者，按照 Windows 性能计数器的说法：
Effective clock = Nominal max clock * "% Processor Performance"
这是任务管理器 GUI 中所有四个内核的平均数。Windows 性能计数器（操作系统的软件级 API/UI）使计数器按内核提供，按 CPU 包汇总，按系统汇总。
这个公式在实验室中（即在健康的系统上）一直对我有用。我还没有找到一个 Windows 性能计数器，它保存着“EIST Max”=“% 处理器性能”的实际“参考框架”，但没关系……我通过在 800 MHz 空闲的健康机器上摆弄 ClockMod 所能得到的最接近的结果是通过 IA32_CLOCK_MODULATION MSR 将两个内核限制为 4/16，将两个内核限制为 5/16。使用 uclewebb 的 MSR 工具完成 - Windows 任务管理器报告的“有效 CPU 时钟”一直在 0.23 和 0.25 GHz 之间切换。
根据几个人的建议，这可能与 PROCHOT 信号或按需节流有关，我拼凑了我自己的工具来访问 MSR_POWER_CTL、IA32_PACKAGE_THERM_STATUS、IA32_THERM_STATUS 和 IA32_CLOCK_MODULATION - 在调查下一个罪魁祸首时，有一些小、简单和切中要点的东西。
今天，罪魁祸首出现了，而且……我有点震惊。没有任何 PROCHOT 源处于活动状态，显然自上次通电以来 PROCHOT 从未发生过，而且“按需节流”（又名 CLOCKMOD）也已关闭。
...CPU 核心 1、2 和 3 也一样。
我们尝试禁用 BD-PROCHOT - 禁用标志保留在 MSR 中，但问题并未消失。这并不奇怪。我们尝试摆弄 CLOCKMOD 位 - 使用另一个工具，该工具执行读取 + 写入 + 读回。该工具有效，但没有带来任何改进（同样不足为奇）。
我还查看了一些 Windows 性能计数器 - 使用 Erwan L 编写的 SnmpTools 中名为 perf32 的命令行程序。输出如下：
"Processor Information\% Processor Performance\_Total"
9.49953814259068
"Processor Information\% Processor Performance\0,0"
9.99836227595223
"Processor Information\% Processor Performance\0,1"
9.00490682886555
"Processor Information\% Processor Performance\0,2"
9.95220023870093
"Processor Information\% Processor Performance\0,3"
8.99923060510645
"Processor Information\% Processor Utility\_Total"
9.15043821293382
"Processor Information\% of Maximum Frequency\_Total"
73
"Processor Information\Processor Frequency\_Total"
1700
"Processor Information\Processor Frequency\0,0"
1700
# the same for CPU core 1,2 and 3
"Processor Information\Processor State Flags\0,0"
1
# the same for CPU core 1,2 and 3
"Processor Information\Parking Status\_Total"
0
"Processor\Interrupts/sec\0"
1979.5905212033
"Processor\% Interrupt Time\_Total"
0.777807192025936
因此... CPU 核心卡在标称的“实际”频率 1.7 GHz，即 2.3 GHz（EIST 最大值）的 75%。按需节流已关闭。但是，某物使 Windows 认为整体“处理器性能百分比”仅为 9% 或 10%。两个核心为 9%，两个核心为 10%，因此系统总体百分比为 9.5%。0.095 * 2300 MHz = 218 MHz。
注意这些百分比及其粒度：9% 和 10%，相当精确。
它如何与整数 EIST 乘数（显然锁定在 17）和 1/16 CLOCKMOD 占空比（首先似乎也是关闭的）相适应？
在计算 CPU 性能百分比时，Windows 还考虑了哪些其他因素？还是只是从硬件中逐字读取？我应该在硬件中检查哪些 MSR，以验证/了解 Windows 报告的数字？
Turbo（EIST 的后继者）是否会使性能控制更加精细，“摆脱 EIST 的限制”，并且是否带来了一些相关的新 MSR？
这些百分比可能实际上是错误的……处于故障状态的罪魁祸首系统实际上可能比百分比所显示的还要慢。仅通过与我的实验室实验进行主观比较，使用 CLOCKMOD 节流，类似的“有效时钟速率”约为 0.25 MHz。
感谢您的时间。欢迎提出任何想法。
编辑：哦该死——是的许多 MSR。我希望 Turbostat 可用于 Windows。
编辑：我编写了一个工具，用于在屏幕上和 CSV 文件中对给定范围的 MSR 进行原始转储。事实证明，MSR 空间相当稀疏……此工具将允许我转储罪犯/患者和健康盒子上的一些有意义的范围，以供比较。比较也可以在一定程度上自动化。然后，我可以根据手边的英特尔手册仔细研究数据，关注差异等。
我也尝试过使用 Windows 版本的 AcpiCA 的 acpidump 等。还没有在有问题的机器上尝试过，但在我的旧笔记本电脑（带有 UEFI 的 2015 款联想）上它找不到 _PSS 对象...我可能会在有问题的机器上再试一次。
答案1
简短的回答：这是英特尔 Haswell CPU 中很少出现的错误，步进 C-0 和 D-0（唯一的步进？）。
发生这种情况的区域是“现代性能和热管理”，其“冰川顶部”表面上可见为状态寄存器 (MSR) 0x690、0x6B0、0x6B1 - 在那里，单个状态标志可以发出有缺陷的状态信号。该状态标志和一些性能计数器可以与原始 TSC 进行比较，其差异可能可以告诉您实际节流的水平......问题在 IA32_CLOCK_MODULATION、旧式 THERM_STATUS MSR 和旧式 IA32_PERF_STATUS/CTL MSR 中是不可见的。
我确实将 MSR 转储到罪魁祸首和运行正常的机器上，在转储之间运行了差异，花了一天时间根据手头的英特尔手册找出发现的差异，并将问题追踪到可能的罪魁祸首，形式为 MSR_CORE_PERF_LIMIT_REASONS（和 MSR_GRAPHICS_PERF_LIMIT_REASONS）中的位 1 =“热状态”。
从此，谷歌找到了我超级用户这里有一个完整答案
一旦出现错误，似乎没有办法清除那个讨厌的过热标志。找到答案后，罪魁祸首仍然处于故障状态，我们尝试在运行时禁用：
- “英特尔动态加速”
- “EIST 硬件协调”
- 涡轮
- 东印度公司
结果似乎证实了普遍的看法——唯一的出路就是动力循环。
还有一个英特尔勘误表，提到这与 C3 C 状态有某种关联 - 所以我敢说阻止比 C1 更深的 C 状态应该可以解决这个问题。检查您的 BIOS 设置。有一个用于 C 状态配置的 MSR，但在我的系统上，该 MSR 在 POST 期间被锁定，因此无法在硬件中在运行时禁用 C3+。
即使硬件/BIOS 路径被阻止，操作系统也可能会在启动时接受建议，而不是要求更深的 C 状态。在 Intel CPU 上的 Linux 中，可以使用引导加载程序中众所周知的内核命令行参数来安排这一点：intel_idle.max_cstate=1。在 Windows 中，显然也有一些方法：有一个 regedit curse，记录不详，但显然颇受欢迎，您可以在其中创建一个特殊的 reg 值来伪造 CPU 功能，使 Windows 避免使用 C2/C3：（reg add HKLM\System\CurrentControlSet\Control\Processor /v Capabilities /t REG_DWORD /d 0x0007e066 来源：A，乙）还有一种替代方法，即通过有功功率曲线（来源- 我不会在这里重复整个过程，关键词是或许powercfg.exe和IDLESTATEMAX 1）。