If you have enough servers for idle draw to be more than a rounding error in your opex breakdown, then you have a strategy to keep idle time to zero. It doesn’t make any financial sense (no matter how low idle draw is) to have a server sit idle (or even powered off, but that’s a capex problem).

Can confirm, built out a datacenter space in a past life. Power costs were of limited concern - cooling was the limited resource. Even then, literally no one went down a spec sheet and compared "hmm, this one has a tiny less amount of watts idle". We just kept servers dark regardless so that we can save on cooling. Nitpicking idle draw for server processors just isn't realistic for a lot of cases.

For a cloud infrastructure, you have a significant part at idle, for when customers want to instantly spawn a VM.

Yeah, I think it's hard to keep your computers at 100% utilization for the entire day. You host services close to your users, and your users go to bed at some point, many of them at around the same time every day. Then your computers have very little work to do.

Some bigger companies have a lot of batch jobs that can run overnight and steal idle cycles, but you have to be gigantic before that's realistic. (My experience with writing gigantic batch jobs is that I just requisitioned the compute at "production quality" so I could work on them during the day, rather than waiting for them to run overnight. Not sure what other people did, and therefore not really sure how much runs overnight at big companies.)

Cloud providers have spot instances that could take up some of this slack, but I bet there is plenty of idle capacity precisely because the cost can't go to $0 because of electricity use. Or I could be completely wrong about workloads, maybe everyone has their web servers and CI systems running at 100% CPU all night. I've never seen it, though.

The target market for this part is not that kind of datacenter.

Based on the article they're targeting high performance compute, i.e. "application codes used in earth system modeling, financial services, manufacturing, as well as life and material science."

The opposite is true... a major advantage of running cloud infrastructure is that you can run your CPUs near 100% all the time. CPUs which are not running full bore can have jobs moved to them.

Or for redundancy sake, if you're using any kind of sane setup. (Yes, YMMV bigly with this particular idea.)

Shouldn't datacenters attempt to minimize idle time though? A server sitting at idle is a depreciating asset that could likely be put to more productive use if tasks were rescheduled to take advantage of idle time (this would also reduce the total number of servers needed).

Utilization is a very difficult problem to solve. The difference between peak and off peak utilization can be as much as 70% or more depending on the application.

That is definitely the objective but the reality is that load is not* uniform over the day. So you are paying to keep some number of servers hot (I don't know about spinup/spindown practices in modern datacenters).

I doubt this applies to HPC (the target market for this part) as they either schedule jobs closely or could, I imagine, shut them down. But I'm not in that space either so this is merely conjecture.

* I am sure there are corner cases where the load is uniform, but they are by definition few.

large datacenters have hardware orchestration systems that let them turn off unused machines. There really is no reason to have lots of machines on but unused. At least, that is not a significant enough event to be a determining factor in hardware purchasing.

If you are the one paying the electricity bills for that datacenter, then yes, it probably matters to you a lot. If you are just renting a server from aws or gcp, it probably matters less. Although, I assume costs born from idle inefficiency will probably be passed to the customer...