[dataflow]

> half-speed for whatever reason

IMHO the reason actually does matter.

Utilization should be relative to the maximum frequency the CPU could be running the same instructions at. If the CPU is throttling to save power, then it could be running the same instructions at a higher frequency, so utilization should be relative to the higher one. If it's throttling to lower the temperature, then it can't be running the same instructions at a higher frequency, so it's already maxed out at 100%.

[nomel]

> If it's throttling to lower the temperature…

This gives the ability to go over 100% before thermals equalize, since max power would follow a Newton cooling curve.

[dataflow]

I don't follow. Whatever frequency the CPU is currently running at is a lower bound on the maximum frequency it could be running at, so it shouldn't exceed 100%?

[nomel]

But the thermals of the system means it can, for short periods of time, run much faster than long periods of time. I don't think a constantly changing 100%, that changes with temperature, is very useful. I would be more interested in whatever the sustainable 100% is, for normal room temperature.

[gruez]

>Utilization should be relative to the maximum frequency the CPU could be running the same instructions at

How do you define "maximum frequency"? For desktops it's relatively easy to define since they usually have good cooling and power delivery that they can always hit the top frequency, but for laptops this often doesn't apply. It might be only able to sustain top frequency for less than a minute before thermal throttling kicks in.

[dataflow]

Whatever frequency it could execute the next cycle at, assuming there was no desire to minimize power usage. It's a transient measure, not a steady-state measure.

[gruez]

This will cause the system to vastly under-report % values during periods of low load, because the processor thinks it can run at a higher frequency than it can actually achieve/sustain. This is most notable on laptop processors. If I enable "high performance" mode on windows, it would cause the processor to run at its max possible frequency, around 4.1 GHz (which is near the theoretical max turbo frequency) when there's little to no load. However, when there's actual load (eg. 1 core fully loaded), the frequency would drop to around 3.5 GHz. It would get worse as more cores get loaded, all dropping all the way down to 2.3ghz.

[dataflow]

What problem would this cause to me as a user, though? It sounds fine to me.

[gruez]

At 5% load, you might think there's 95% capacity to spare, but really it's actually something closer to 65%.

[dataflow]

3.5 GHz instead of 4.1 GHz is a 15% difference, not 30%. I never expect multicore performance to be the same as single-core so if that's what you're assuming, it's an unreal assumption. I expect lower clock speeds for multicore regardless of what Task Manager shows.

But okay, so there's some discrepancy, whether 15% or 30%. Okay, so I might underestimate it, and... then what? What would actually go wrong?

I think what you're not realizing is that underestimating capacity is a very different situation from overestimating it (especially when we're talking about underestimating like 0.4 GHz vs. 4 GHz, as opposed to overestimating 2-3 GHz as 4 GHz). When I'm looking at CPU usages it's almost always to figure out who's overutilizing the CPU, not underutilizing it. If I underestimate utilization, then at worst, what happens is I launch a program that needs all cores for max throughput (say a video encoder?), and then get disappointed at its throughput being too small. This is so infrequent (if it happens at all for the average user) that the additional mental effort required to factor in the throttling is quite negligible, and the negative consequences are quite mild. Compare that to the case where I overestimate utilization: suddenly I semi-panic and try to kill the program using the most CPU, and boom, suddenly I'm at risk of losing a bunch of data. The difference is quite asymmetric.

[Godel_unicode]

The manufacturer doesn't know this, nor is it easy to determine. Is the max turbo frequency on air the max? On water (if so with what size rad with which fans)? At what ambient temperature? Is the max including tau, if so does that max change when it's about to expire? What about if the CPU was on ln² but the user has run out and can't add more to the cooling pot?

Every one of those numbers is different, and frequently the only way to determine if a frequency is possible to use for stable operations is to try it and see.

[dataflow]

No, you're just making this hard. Just imagine the CPU decided it wouldn't deliberately throttle its frequency to save power. Obviously nothing stands in its way of doing that; that's what it would do if they didn't deliberately tell it otherwise. Now what frequency would it execute the next cycle at? Obviously it decides on some frequency, and it does that without you telling it whether it's air or water cooled. Whatever number it would decide on: use that number.

[Godel_unicode]

Sometimes reality is hard :) One source of CPU throttling which you appear to be ignoring is temperature. Another is platform power delivery. Both are not always knowable by the CPU in advance. The CPU obviously doesn't "decide on a number" by itself. Sometimes it asks for a certain voltage but because of Tau it gets a lower one. Sometime it starts to boost because of demand only to immediately thermal throttle and run slower.

You cannot deterministically know what max frequency the CPU could be running at in some future demand/power/temp state.

[nightpool]

that doesn't solve the "relative measures make the graph useless" problem though, does it?

[dataflow]

Hm I felt it does, but I might've missed some situation. Why do you feel it doesn't? Could you describe a scenario where it'd be misleading?