WattWise is a CLI tool that monitors my workstation’s power draw using a smart plug and automatically throttles the CPU & GPUs during expensive Time-of-Use electricity periods. Built with Python, uses PID controllers for smooth transitions between power states. Works with TP-Link Kasa plugs and Home Assistant. |
Looks like it’s just a display.
The consensus thus was that spending more time in lower power states (where you use ~0W) was much more efficient than spending a longer amount of time in the CPU sweetspot, but with all sort of peripherals online that you didn't need anyway.
I remember when Google made a big deal out of "bundling" idle CPU and network requests, since bursting them out was more efficient than having the radio and CPU trotting along at low bandwidth.
Manufacturers chase benchmark results by youtubers and magazines. Even a few percent difference in framerate means the difference between everyone telling each other to buy a particular motherboard, processor, or graphics card over another.
Amusingly, you often get better performance by undervolting and lowering the processor's power limits. This keeps temperatures low and thus you don't end up with the PC equivalent of the "toyota supra horsepower chart" meme.
1400W for a desktop PC is...crazy. That's a threadripper processor plus a bleeding edge top of the line GPU, assuming that's not just them reading off the max power draw on the nameplate of the PSU.
If their PC is actually using that much power, they could save far more money, CO2, etc by undervolting both the CPU and GPU.
OTOH, if it's something like realtime game rendering without a frame limiter, throttling would reduce the frame rate, reducing the total amount of work done, and most likely the total energy expended.
The ideal form factor might be a smart plug itself, but I can’t find any with hackable firmware and also matter/thread/wifi.
The dual Epyc CPUs (128 cores) in my setup have a relatively high idle power draw compared to consumer chips. Even when "idle" they're consuming significant power maintaining all those cores and I/O capabilities. By implementing uniform throttling when utilization is low, the automation actually reduces the baseline power consumption by a decent amount without much performance hit.
We don't pay for electricity directly (it's included in the rackspace rental), but we could reduce our carbon footprint by adjusting the timing of batch processing, perhaps based on the carbon intensity APIs from https://app.electricitymaps.com/
Though, the first step will be to quantify the savings. I have the impression from being in the datacentre while batch jobs have started that they cause a significant increase in power use, but no numbers.
Only really makes sense for learning or super confidential info
The current implementation uniformly sets max frequency for all 128 cores, but I'm working on per-core frequency control that would allow much more granular optimization. I'll definitely measure aggregate consumption with your suggestion versus my current implementation to see the difference.
Ideally these goal are balanced (in some 'efficient' way) against matching electricity prices. It's not either/or, you want to do both.
Besides better amortizing the embodied energy, improving compute utilization could also mean increasing the quality of the compute workloads, ie doing tasks with high external benefits.
Love this project! Thanks for sharing.
[1] https://forums.anandtech.com/threads/embodied-energy-in-comp...
The stuff the chip and motherboard do, completely built-in, is light-years ahead of what you're doing. Your power-saving techniques (capping max frequency) are more than a decade out of date.
You'll get better performance and power savings to boot.
This core will get to sleep less than the others.
You can also use the CPU "geometry" (which cores share cache) to set max frequency on its neighboring cores first, before recruiting the other cores
That said, I'm definitely interested in learning more about processor-specific optimizations for EPYC. If there are server-focused equivalents to what you've mentioned that would work better than frequency capping, I'd love to explore them!
It lets you set specific power consumption limits in W instead of attempting to do the same by restricting maximum core frequencies (which could also be useful in addition to overall power limits).
https://octopus.energy/blog/agile-smart-home-diy/
https://www.zerofy.net/2024/03/26/meter-data.html for some more European info on meters, though mostly focused on accessing your own usage data.
Smartphone chips are designed to much stricter thermal and power limits. There is only so much power you can get out of the tiny battery, and only so much heat you can get rid of without making the phone uncomfortably hot. Even in a burst that puts a limit on the wastefulness. Desktop CPUs are very different: If you can get 10% more performance while doubling power draw, people will just buy bigger coolers and bigger power supplies to go along with the CPU. Notebook CPUs are somewhere in the middle: limited, but with much better cooling and much more powerful batteries than phones.
The other thing is the operating system: "race to idle" makes sense in phones because the OS will actually put the CPU into sleep states if there's nothing to do, and puts active effort into not waking the CPU up unnecessarily and cramming work into the time slots when the CPU is active anyways. Desktop operating systems just don't do that to the same degree. You might race to idle, but the rest of the system will then just waste power with background work once it's idle.
What has happened is they realised waking up CPUs to do individual tasks was inefficient and stopped CPUs sleeping so they batched work together but that is basically the overhead of going in and out of sleeping which presumably does waste a bunch of power. This also explains why so many high end phones now have 1 ultra slow core that deals with the background stuff when the phone screen is off, the rest can all just sleep and this low power core can sit there on low clocks sipping minimal power most of the time.
No they won't. OEMs will do that to put the 10% higher number on the box ('OC edition!'), but undervolting / powerlimiting has become increasingly popular. Taking a 2-5% haircut on clock frequency lets you reduce power draw by 20-50% for a 1-3% haircut in performance. Suddenly your CPU and GPU are whisper quiet on aircooling.
For a desktop, the usage… I mean, it is sort of different really. If I’m writing a Tex file for example, slower compiles mean I’ll get… fewer previews. The screen is still on. More previews is vaguely useful, but probably doesn’t substantially speed up the rate at which I write—the main bottleneck is somewhere between my hat and my hands, I think.