Research notes / SSD measurement
SSD steady state is not a timer
12 October 2026 / Source review and synthetic counterexamples
A fixed warm-up period does not demonstrate stable SSD performance. State the workload and the acceptance rule, retain the full trace, and check both variation and drift. Even a passing window cannot promise what happens next.
The device has a history
The FAST 2018 MQSim paper identifies three history-sensitive mechanisms: garbage collection begins as free pages become scarce, a warmed write cache changes backend traffic, and previous placement affects available parallelism. Its preconditioning model initializes valid/invalid page distributions and warms the cache using trace characteristics. Simply marking capacity as occupied is not an equivalent initialization. [1, sections 3.2, 4.4 and 5]
This is a simulation-methods result, not a performance promise for every SSD. The authors compare modeled and measured behavior on four devices, including replay of three traces; their Appendix A describes parameter estimation and validation. We did not run MQSim or reproduce its device experiments. No published speedup is transferred to current hardware here. [1]
A useful benchmark question is therefore specific: sustained random overwrites over which addresses, after which preparation? A short burst and a sustained write run answer different questions. Neither should silently stand in for the other.
Two checks, one explicit denominator
SNIA SSS PTS 2.0.2 defines a five-round measurement window. Clause 2.1.24 checks both the observed range against 20% of the mean and the fitted-line span against 10% of that mean. Its preconditioning distinction is between a prescribed preparation workload and the test workload itself. A round is a complete test pass, not automatically one second. [2]
For our equally spaced indices x = 0, 1, 2, 3, 4, letm be the five-value mean and b the ordinary least-squares slope. Then:
- Observed range:
R = 100 (max(y) - min(y)) / m. - Fitted span:
T = 100 |b| (4 - 0) / m. - Example acceptance:
R <= 20andT <= 10.
Multiplying the slope by the index span matters. A slope measured in IOPS per round cannot be compared directly with a total percentage change across the window. We implement inclusive boundaries following the clause's "no more than" and "within" wording; the module is not a complete PTS conformance test.
Small slope is not small variation
These are invented arithmetic inputs in IOPS, deliberately small enough to inspect by hand. They are not observations from a drive. All three plots use the same zero-based vertical scale, from 0 to 120 IOPS.
| Case | IOPS in rounds 1-5 | R | T | Both checks |
|---|---|---|---|---|
| small-variation | 100, 102, 99, 101, 98 | 4.0% | 2.0% | Pass |
| gradual-drift | 92, 96, 100, 104, 108 | 16.0% | 16.0% | Fail |
| symmetric-swings | 88, 112, 100, 112, 88 | 24.0% | 0.0% | Fail |
| early-plateau | 200, 200, 200, 200, 200 | 0.0% | 0.0% | Pass |
| later-plateau | 100, 100, 100, 100, 100 | 0.0% | 0.0% | Pass |
| asymmetric-excursion | 95, 95, 115, 95, 100 | 20.0% | 4.0% | Pass |
The rising sequence stays inside a 16% range, but its fitted change is also 16%: the trend rule rejects it. Symmetric swings have zero fitted slope but a 24% range: the range rule rejects them. These checks catch different defects.
The asymmetric case also matters. Its mean is 100, its range is 20 and its fitted span is 4. It passes our two checks, although 115 is more than 10% above the mean. A max-minus-min limit is not identical to requiring every point within a symmetric band around the mean.
Finally, concatenate the early and later plateaus. Each five-round window passes, yet performance halves between them. This constructed counterexample proves only that a local acceptance rule cannot guarantee future behavior. It does not estimate how frequently real drives behave this way.
Download the CSV, provenance JSON and dependency-free evaluator. Tests cover boundary values, reversal, scaling and invalid inputs. No device I/O is performed.
Three fio controls that are not interchangeable
ramp_time runs the workload before performance logging. steadystate_ramp_time delays collection for the steady-state termination decision. steadystate selects an actual stopping criterion, evaluated over steadystate_duration with samples separated by steadystate_check_interval. A delay alone does not check convergence. [3]
fio's deviation criteria and slope criteria are separate options; a percentage setting must be interpreted in that option's own units. Do not label one fio setting a complete implementation of the SNIA procedure. Preserve the version and job file alongside the result. This review follows documentation revision 3.42-115-gcd29, not a hardware run. [3]
What to retain with a result
For a reviewable comparison, we recommend recording the target identity and firmware; address span and occupancy; preparation and discard history; block sizes, read/write mix, access distribution and achieved concurrency; bytes written before measurement; the full per-round series; and the exact acceptance calculation. Keep separate latency distributions when latency matters.
Report a failure to converge as a result, not as permission to select the smoothest-looking interval. A low but flat throughput is still low. Stability is not a minimum-performance target, and average IOPS alone cannot establish tail latency, power-loss durability or reliability.
All writes used for device preparation can overwrite data and consume endurance. We supply no raw-device write command and ran no conditioning workload. Any later hardware study needs an explicitly disposable target and a documented test budget.
Corpus: SSD steady state, preconditioning and active LBA range. Related: discard semantics and thermal throttling.
Primary sources and scope
- Arash Tavakkol, Juan Gomez-Luna, Mohammad Sadrosadati, Saugata Ghose and Onur Mutlu. MQSim: A Framework for Enabling Realistic Studies of Modern Multi-Queue SSD Devices. FAST 2018, pp. 49-66; sections 3.2, 4.4, 5 and Appendix A.
- SNIA. Solid State Storage Performance Test Specification, version 2.0.2 (1 October 2020), definitions 2.1.1, 2.1.3, 2.1.6, 2.1.13, 2.1.18 and 2.1.24.
- fio documentation, revision 3.42-115-gcd29: ramp_time and steady-state assessment options. Rolling documentation accessed 11 October 2026.
Sources reviewed 11 October 2026 UTC. Original examples and code: CC0. Source publications retain their rights. No sampled population, observation period, confidence interval, benchmark result or vendor ranking is claimed.