Even the 2012 data is suspect.

"Seek + rotational delay halves every 10 years" just isn't true. We got rid of the >7200 drives and are basically sitting still on that metric. And hard drives weren't at 400MB/s in 2012 either. (The disk bandwidth section also cites a 2012 presentation with correct numbers, but something went wrong in translation.)

Yeah, I was wondering where the heck 2ms disk seek times came from. That's not a thing and will never be a thing; disks only spin so fast, and nobody even uses >7200RPM drives any more (because we've all moved to SSDs instead).

Oh 7200 drives are used. Mainly for large data storage. If you deal with high quality videos (RAW 4K or 8K), SSDs are way too expensive to store them.

GP was likely refering to extraordinary disks with more than 7200 rpm

10KRPM SAS drives in my SAN.

The parent comment said no one uses drives strictly faster than 7200.

Pretty sure 10K RPM drives are used too.

They're used, but rare because they got to a weird position in between slower drives that are cheaper to produce and operate and SSDs. E.g. 15K RPM drives were a thing but while you can still buy some models they're typically more expensive than SSDs, so you mostly buy them to replace drives in existing arrays.

I have no opinion on the matter, just pointing out that your comment doesn't follow from the previous one. But I imagine that when they said "nobody" uses faster disks, they were exaggerating a bit. The question is whether the default set of "latency numbers everyone should know" should reference SSDs or uncommon spinning disks.

Looks like a fun project to bring it up to date.

Where would one lookup such data, if one is interested in updating the code.

I would start by going through the Anandtech reviews of the major processor and storage announcements. They generally do a great job of benchmarking and go into pretty good detail. Datasheets from manufacturers would also be useful although not all data is routinely provided.

This is the kind of thing you’d typically experimentally verify rather than look up.