51–60 of 181 posts
I think we can have more nuance than a choice of 50% or 100%. I fall in the 'Show 100%' camp for sure, showing 50% but not indicating why isn't particularly helpful without knowing the background here. I think a separate indicator for an overall throttling condition would be helpful. Show a 100% usage and a throttle indicator together.
Agree, you really want 2 indicators, vs 1 confusing hybrid.
Related, 50% CPU usage on a hyper-threaded CPU isn't 50%. It is usually closer to 80-90% depending on the workload. Something to watch out for when monitoring.
It's the testing problem: Trying to report squish too many numbers into one. The right reporting is to report both the numerator and the denominator. I'm using 800 MIPS out of 1200 MIPS available.
It's the testing problem: Trying to report squish too many numbers into one. The right reporting is to report both the numerator and the denominator. I'm using 800 MIPS out of 1200 MIPS available.
If my processor is marketed as 1200 MIPS but can run at 2000 MIPS for up to 0.5 seconds out of every 15 second window (due to thermal constraints), but only up to 1700 MIPS when executing SIMD instructions for 0.5 seconds and 1000 MIPS thereafter, and only up to 900 MIPS when it gets too hot because my laptop is sitting on a blanket instead of a hard surface, what is the correct denominator?
One representation is a line graph with two lines -- one is showing the maximum MIPS (right now), and one is showing the actively-used MIPS.
Another is a pie chart, where the size is the chart changes based on current capacity, and it is filled to how much of that capacity you're using.
And so on.
You have two dimensions. You don't want to squash that into a 1D representation.
Earlier quoted context omitted.
Interesting. Does this mean that if you are not going to use all HT threads it's better to turn off HT?
SMT is usually a throughput win, and usually a latency loss. I was playing with my Threadripper a while back and for C++ builds of large projects, HT results in about a 10% improvement in compilation speed. 10% is a big deal and you should take it. The downside is that games had noticeably lower framerates even with the rest of the CPU idle (at least the games I play are bounded by single-thread performance across ma…
That's not really true, you can mix and match memory, and you might not get ideal bandwidth, but for a lot of uses it's just fine.
This is precisely why all of the large volume cloud server farms I worked with turn off throttling: they need 100% predictable CPU utilization. I worked on power control strategies at Intel for quite some time, and we would often joke in server (Xeon) parts that it was pointless because all of our work was disabled. Early throttles were 50% duty cycles, then L1 bubble injections, then V/F frequency scaling. The autho…
I have managed several extremely large fleets of computers and I can tell you they all use frequency scaling. I seriously doubt that your statement applies to "most server farms" when properly weighted.
“I’m using 100% of my cpu but I’m only at 1.2GHz, something is wrong”