It's time to stop fearing CPU power management Over the past few years, we’ve seen the thermal design power (TDP) of all manner of chips creeping steadily higher as chipmakers fight to keep Moore's Law alive, while continuing to deliver higher core counts, faster frequencies, and instructions per clock (IPC) improvements on schedule. Over the span of five years, we’ve seen …
In current operating systems it is too cumbersome to switch between modes, like browsing, gaming and what is in between. Power profiles are vey simplified. They should include which devices should be excempted and which can be switched off. There are huge savings possible but os, cpu and expansion cards vendor believe power is endless and are far from providing easy to change power settings. Probably 90% of users in corporate or home settings use much more cores and power they really need. Even when improvements will cone due to installed base it bay need decaded to finally get savings. Without regulation probably nothing will change.
I hate when my gaming rig sounds like a harrier jump jet (unless i'm playing Tiny Combat Arena, I guess..). I'm all for power-saving options on computers. I think the reasons for resistance are largely historical - back in the day the first things you did when building any PC was turn off "all the power-saving crap" because you know that when you need it it would need time to spin up and you'd get jitter and hangs whilst it did that.. These days I have to say it mainly works pretty well, able to determine how much load is put on components and alter their behaviour pretty seamlessly.
This is similar to the rope-a-dope we had with the old P4 architecture. We were selling a lot of Pentium 3's and even mobile P4's to some customers as their power budgets just couldn't handle the extra watts banks and banks of the newer processors required. So, the more things change, the more they stay the same.
In large scale manufacturing there is or used to be a cost engineering department. Back in the days of discrete components can we use cheaper 10% tolerance resistors, are we paying too much for plastic ties, can this product be re-engineered and so on. Doesn't seem yet to.apply to data processing.
Will data centre operations ever reach the stage of people questioning whether they need a Porsche to nip out to buy the groceries?
Just musing as I read articles suggesting that computing is consuming 110% of the world's electricity consumption and comments on other articles here decrying re-using data centre heat generation to heat swimming pools.
If home panels can disable the other higher amperage circuits when more than 2 of them are on (in this age of PV arrays and home batteries providing plenty of juice but well below modern domestic official kW provision numbers), then I suspect a rack can do something a little more subtle. I'm expecting a power router per rack just like the network router per rack. With hooks to the host kernels, even, for keeping load down when a node is told what its power budget is.
So now we know why the Tesla automobiles can't do all the wondrous and magical things which have been predicted claimed for them--and still are--since day one.
If the battery would simply support the inclusion of thirty or so Sapphire Rapids, or Epyc 4s (running full-tilt, of course), the Tesla(s) just might be able to replicate the Cruise Control feature of the 1979 Oldsmobile...
Large (distributed batch) workloads typically require some scheduling to ensure that you don't end up waiting for a slow task to complete at the end of the run. To get best utilization you try to schedule those long running tasks early on in the batch, and typically you work out which of those tasks are going to be long running by looking at how long they ran in the previous batch run... We have see power management throttling add 30% to a run time - and thus muller the scheduling of that batch *and* the subsequent batches. Sure you can do all kinds of clever statistical analysis - but in practice that doesn't necessarily help as much as you might hope when your wall clock run-times can be +/- 30% depending on the phase of the Moon.
I do agree with the premise though : grow the eff up and deal with variable runtimes ... It's just that Java boyos calling out to C++ libraries don't deal with it in practice - it's beyond their pay grade.
Phone rings\Email plonks into my inbox\Sales clone winges over the cube wall....
Luser: My new ( insert model name ) server keeps locking up ..
Me: OK. lets review your BIOS settings. Do you have all sleep states disabled?
Luser: Wha? uuh no .. Our deployment document says to keep them turned on ..
Me: Who wrote your deployment document .. ( I ask, already knowing the answer ... )
Luser: .. umm .. your Sales guy sent it ... Its marked "( corp name ) Advanced Marketing "Hot Note" briefing white paper Internal only, not for general distribution, do not forward under threat of death or loss of quarterly bonus. Seriously. don't do it "
Me: Yea, Im gonna need you to turn those sleep states off .. or ( checks the magic 8-ball ) your toaster oven might flame out ..
Luser: OH OOHHH OOOHHH ... ok.. pizza rolls.. good
Me: Thanks for calling .. Click
Searches corp directory for sales clone, looks around for the quick lime . "And, that's one hour for lunch" ..
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
