3 ms·
This usually isn't true at scale though. The chip manufacturers do a ton of validation and qualification to set the operating parameters (voltage, etc). You ca
by bradstewart 4y ago
This usually isn't true at scale though. The chip manufacturers do a ton of validation and qualification to set the operating parameters (voltage, etc).
You can undervolt (or overclock) one specific chip, individuals have been doing this at home for basically ever, but there's (almost) always a system-specific validation process you then do to make sure the system is stable for a specific workload with the new parameters.
And these parameters differ between batches of chips, or even between chips within a batch.
It's also significantly harder to drastically reduce the temperature of the chips inside of a single server, given the machine density of a typical data center.
- rbanffy 4y ago> It's also significantly harder to drastically reduce the temperature of the chips inside of a single server, given the machine density of a typical data center. It’d be fun, however, if we could dynamically adjust that according to workload. If workload is light, you could consolidate load into fewer sockets/memory sticks and power down everything in that socket.
- salmo 4y agoIt’s been a while since I was doing hardware in a DC, but even dynamic frequency changes in servers were noticeable in workloads. We’d see serious latency spikes with high volume increases. And high volume would correlate to high I/O on shared storage exacerbating the problem. You’d get a bunch of transactional failures from the spontaneous latency hit. Same was true with older virtualization/partitioning of hardware. You’d even see apps back up into memory and swap themselves to death. Now, the apps were awful: inefficient and intolerant. But that’s the reality for the vast majority of business software. Churned out by devs with little understanding and tight timelines for features. Reliability being an NFR kills me.