Storage performance is often summarized in terms of throughput, in B/s, and IOPS, which is a unitless number. I understand that in principle an IOP is an “IO Operation”, i.e. a single disk read or write, etc. On an HDD, in the general case, my understanding is that an IOP may require a disk seek, i.e. may require the read head to reposition.
What I’m not clear on is whether an IOP corresponds to reading only a single sector on the drive (4K), or whether a larger contiguous read/write could count as one IOP. If anybody knows the nuts-and-bolts of this, I’d love to be enlightened
Yes, it os level request for block of certain size from target device.
IOPS measure how many such request can successfully retrieved from target device per second.
Since both pattern of request and kind of request can also vary, thats why measure read, write, random, sequential and mix separately for each byte length.
And thats just the beginning of the benchmark rabithole, since modern ssd drives are complex devices with variable internal states → performance testing reuquires very specifically crafted request profiles.
E.g. enteprise class drive are desined around much different engineering targets, so they will perform underwhelmingly in simple tests, but be entirely unbeatable at sustained requests and heavy simultaneous requests.
I.e 3000 USD 1,6 TB intel DC3600 will have half to third 4K RRW @ QD1T1 compared to simple samsung 980 nvme ssd, but be strong ion other areas.
That is pretty much the opposite of what the Wikipedia article says.
Like anything else, this depends on your application.
If you are hosting a bunch of VMs, doing a highly varied mix of I/O, then IOPS might be more useful than raw read/write rates.
If you are hosting a database (or several) with a tendency to do lots of small I/O, then IOPS might be a more useful predictor of performance.
If you are a gamer … not a clue, as not a gamer. Suspect IOPS is less interesting, at least if the software developer spent any time optimizing I/O. Or more important if the developer is terrible at I/O.
A few years ago, put together a storage system for a high-end gadget. As I controlled I/O patterns, the critical bit was doing large writes, not lots of small stuff. Used consumer drives with best write rates - and the built system met and exceeded requirements.
Nothing is optimized in software development unless it has to And in Gaming it’s a mess more often than not.
Gaming is a mixed workload. You load the foundation/base of the assets into main memory (mostly) sequentially and during runtime dynamically load assets as gameplay demands. Because the average target system has less memory and VRAM than the game requires, even if you compress the assets as it is commonly done.
This is why you have such low memory requirements for Gaming. Because the objective isn’t to load everything into memory. If I have a 200GB database in the enterprise, I get 200GB of memory or more for that very database. But the market for gaming hardware currently sits between 8-32GB of main memory and the customers don’t want to pay for 256GB of memory for their game which has 200GB of assets. Gaming hardware has to be cheap, performance is of secondary concern.
So you still have to deal with random I/O during runtime while also not overwhelming CPU with heavy compression. Large games have millions of files and a lot of small stuff. We’re talking 99% reads here.
But there are exceptions as well. Especially Indy games (or lower budget productions) tend to have a lot of random I/O for initial startup. Games like KSP or Ark are probably the poster childs of this approach. So quality and optimization can vary greatly.
And this random I/O is the reason we prefer SSDs for gaming. Large array of HDDs and 4GB/sec sequential read only gets you comfortably to the title screen and breaks down afterwards because HDDs inherent weakness in random I/O / IOPS.
Startup time for games is an important metric for most people. I’d rather load everything into memory at start and send my drives into stand-by/sleep.
Loading message is mostly associated with storage, but often it’s inefficient code waiting using CPU cycles while storage is mostly idle. Most of the time when I see the game states “loading”, drives are doing barely a thing but CPU cycles work like crazy.
And in Gaming it’s a mess more often than not.