This is the so-called open-loop versus closed-loop issue.
Real world applications don't typically control for constant queue depth. Rather, they have some typical (average) throughput, which means that any "hiccups" in storage latency cause many IOs to "back up" and spike QD.
It we tested this way, it would be more realistic. The high-percentile latency outlier metrics (things like 5-nines latency) might be more representative of what a real app could expect.
First we'd have to run some kind of "probe" to determine the peak IOPS of the device, and then divide that range into discrete tests (something like 10%, 20%, etc.). The IO generator and preconditioner would need rate-limiting support as an alternative to the "-o" queue depth argument.
This is the so-called open-loop versus closed-loop issue.
Real world applications don't typically control for constant queue depth. Rather, they have some typical (average) throughput, which means that any "hiccups" in storage latency cause many IOs to "back up" and spike QD.
It we tested this way, it would be more realistic. The high-percentile latency outlier metrics (things like 5-nines latency) might be more representative of what a real app could expect.
First we'd have to run some kind of "probe" to determine the peak IOPS of the device, and then divide that range into discrete tests (something like 10%, 20%, etc.). The IO generator and preconditioner would need rate-limiting support as an alternative to the "-o" queue depth argument.