This is a single value, averaged over all four cores. Under normal circumstances, in Windows or Linux at a typical workload = idle, the CPU frequency just stays put at 800 MHz (790 MHz reported) i.e. The reference clock appears to be 100 MHz from the onboard clock synth (actually more like 98 MHz, apparently). Turbo can boost up to 3.3 GHz single core, 2.9 GHz across all cores. The CPU's nominal clock frequency (the one printed on the tin) is 1.7 GHz. Nominally a "mobile" CPU - athough the machine is not a notebook, does not have a battery. The CPU is a Haswell Core i7 Core i7-4650U: dual-core with HT, 15W TDP, actually consuming maybe < 5W at idle. There are no local environmental factors or other circumstances to correlate this behavior to. In production, the machines actually run nearly idle for months - verified by some relevant messages in the Event Log, saying that the CPU has been at the lowest EIST clock for another day - this for 100+ consecutive days, until a power-cycle. Verified by generating 100% CPU load for a few days, while recording the coretemp sensor. The machines run cool, far away from thermal throttling thresholds. The effective average MTTF so far has been about 20 years, i.e. Windows Task Manager in 2012 reports the CPU clock firmly at "0.22 GHz", which is a weird value. The problem: on a couple dozen pieces of a PC running Windows Server 2012 R2, "every now and then" at random, some random machine starts to "ooze like molasses". After today I am wondering: "what do Windows know that I do not" ? I must be missing some sweet secret - another MSR or clock steering mechanism. It's not EIST, it's not PROCHOT, it's not CLOCKMOD. But, the first results are perplexing to me. Caught one culprit in the field and this time we were somewhat prepared. This time I have enough data to be more specific. You may remember my inappropriately broad question a while ago. Note: this question is a duplicate of a prior question that has received a pretty detailed answer.
0 kommentar(er)
