Re:Intel Kills Off All Optane-Only SSDs for Consumers, No Re...
by Dylan16807 on Sunday January 17, 2021 @09:25AM
(#25810839)
> The other reason Optane excels is latency.
It's not an "other reason". IO operations at queue depth 1 are a direct measurement of latency. Queue depth 1 is not about throughput at all.
> Suppose the workload is light, at only 500 IOPS, which are "small" enough to service quickly.
I will assume the workload is light in CPU too, since spending half the time waiting for the disk is apparently not an instant disqualification.
> So disk A is in fact actually 1000x faster, if you're waiting on its result. Which, for single-threaded operations, you often are. If you're instead optimizing for throughput, you don't care.
If you're waiting on a bunch of results and disk A gets them to you significantly faster, it sounds like your initial premise of "only 500 IOPS" was wrong or misleading.
If you have a response time you want to meet, then you should measure IOPS with a sliding window of that many milliseconds. If it's still 500 at most, then disk B will still be fine for meeting your target.
If it turns out that "500" actually comes in bursts of 50 operations, and you want to be done in 10 milliseconds, then you should label your workload as "5k IOPS". Put in a drive that does at least 10k and you'll see all calculations done in under a frame; basically perfect latency. A drive a million times faster would have no practical difference.
It's not an "other reason". IO operations at queue depth 1 are a direct measurement of latency. Queue depth 1 is not about throughput at all.
> Suppose the workload is light, at only 500 IOPS, which are "small" enough to service quickly.
I will assume the workload is light in CPU too, since spending half the time waiting for the disk is apparently not an instant disqualification.
> So disk A is in fact actually 1000x faster, if you're waiting on its result. Which, for single-threaded operations, you often are. If you're instead optimizing for throughput, you don't care.
If you're waiting on a bunch of results and disk A gets them to you significantly faster, it sounds like your initial premise of "only 500 IOPS" was wrong or misleading.
If you have a response time you want to meet, then you should measure IOPS with a sliding window of that many milliseconds. If it's still 500 at most, then disk B will still be fine for meeting your target.
If it turns out that "500" actually comes in bursts of 50 operations, and you want to be done in 10 milliseconds, then you should label your workload as "5k IOPS". Put in a drive that does at least 10k and you'll see all calculations done in under a frame; basically perfect latency. A drive a million times faster would have no practical difference.