4 ms·

Many server PSUs can report those values. `ipmitool dcmi power reading` might give good results, but most server vendors have their own tooling that gives more

Many server PSUs can report those values. `ipmitool dcmi power reading` might give good results, but most server vendors have their own tooling that gives more detailed results. If you are into overspending on PSUs you can get similar features in consumer PSUs, for example [1]. But at that point we have completely left the realm of "simple interface". If you want to get a whole-system overview the PSU values are obviously better. But one of the biggest power consumer in many servers are the fans, and because they react to temperature sensors they always lag behind what's actually happening. That makes attributing a rise or fall in power tricky at sub-minute timescales. That's where CPU energy use is much more useful, even if it's a less complete picture. 1: https://www.thermaltake.com/toughpower-irgb-plus-850w-gold-tt-premium-edition.html https://www.thermaltake.com/toughpower-irgb-plus-850w-gold-t...

jeffbee 2y ago
> because they react to temperature sensors they always lag Why don't systems drive the fans based on the VR state instead of lagging temperature readings?
- kube-system 2y ago
  Ambient temps aren't always a constant? Nor is the end-to-end performance of the cooling solution?
  - jeffbee 2y ago
    I'm not suggesting that the fan control should be open-loop with respect to temperature, only that temperature is lagging but voltage and current are leading, so if the CPU is going to ask for a massive step change in power the platform can look at that and precharge the fans.
    - kube-system 2y ago
      I guess you could, but what would you gain? You can't dissipate the heat until it reaches the heatsink anyway. And for bursty workloads you might not even know whether or not you're going to need it. The point of the thermal solution is just to keep the chip from throttling or destroying itself, and direct measurement is plenty quick enough to accomplish that.
    - ssl-3 2y ago
      In the past, I've used things with load-dependent (instead of temperature-dependent) fan speeds. It can seem like it is a simpler method of control (why measure temperature if we don't have to?). But they were really very annoying to be around. It wasn't so bad with constant loads, but bursty dynamic loads created an audible cacophony that was very distracting. Such a system also doesn't necessarily take into consideration other things that affect cooling performance, like ambient temperature and dust. At least one of the problems (the annoying sounds) can theoretically be worked around by slowing down the rate at which a fan ramps up and down. But by the time that is done, fan speed is back to lagging again -- we're heading back to where we were before. And then we still have variables like ambient temperature, dust, degraded thermal interfaces, and others to contend with. So, the simpler method seems to be what we broadly already do today: We change fan speeds based on the temperature of the thing being cooled. This temperature already has everything we need integrated to begin with: It includes thermal output, ambient temp, dust, old thermal goop, and everything else. If thing is cool (for whatever reasons it is cool -- maybe it's idling in a shed in January in Minnesota), then: Fan can go slow or even turn off. If thing is hot (for whatever reasons it is hot -- maybe it's doing real work in a shed in August in Minnesota and full of cat hair), then: Fan can go faster.

jeffbee 2y ago

> because they react to temperature sensors they always lag Why don't systems drive the fans based on the VR state instead of lagging temperature readings?

kube-system 2y ago
Ambient temps aren't always a constant? Nor is the end-to-end performance of the cooling solution?
- jeffbee 2y ago
  I'm not suggesting that the fan control should be open-loop with respect to temperature, only that temperature is lagging but voltage and current are leading, so if the CPU is going to ask for a massive step change in power the platform can look at that and precharge the fans.
  - kube-system 2y ago
    I guess you could, but what would you gain? You can't dissipate the heat until it reaches the heatsink anyway. And for bursty workloads you might not even know whether or not you're going to need it. The point of the thermal solution is just to keep the chip from throttling or destroying itself, and direct measurement is plenty quick enough to accomplish that.
  - ssl-3 2y ago
    In the past, I've used things with load-dependent (instead of temperature-dependent) fan speeds. It can seem like it is a simpler method of control (why measure temperature if we don't have to?). But they were really very annoying to be around. It wasn't so bad with constant loads, but bursty dynamic loads created an audible cacophony that was very distracting. Such a system also doesn't necessarily take into consideration other things that affect cooling performance, like ambient temperature and dust. At least one of the problems (the annoying sounds) can theoretically be worked around by slowing down the rate at which a fan ramps up and down. But by the time that is done, fan speed is back to lagging again -- we're heading back to where we were before. And then we still have variables like ambient temperature, dust, degraded thermal interfaces, and others to contend with. So, the simpler method seems to be what we broadly already do today: We change fan speeds based on the temperature of the thing being cooled. This temperature already has everything we need integrated to begin with: It includes thermal output, ambient temp, dust, old thermal goop, and everything else. If thing is cool (for whatever reasons it is cool -- maybe it's idling in a shed in January in Minnesota), then: Fan can go slow or even turn off. If thing is hot (for whatever reasons it is hot -- maybe it's doing real work in a shed in August in Minnesota and full of cat hair), then: Fan can go faster.