Test methodology
How the benchmarks work
Jazz Disk Bench measures storage read and write throughput. The website reports the mean for each Model, capacity and platform, together with the sample count.
Four measurements, four different workloads
- Sequential read
- Reads a continuous test file. Useful for understanding large-file read performance.
- Sequential write
- Writes data sequentially. Useful for understanding large-file write performance.
- 4 KiB random read
- Reads 4 KiB blocks from different file locations, with queue depth 1 and one thread (Q1T1).
- 4 KiB random write
- Writes 4 KiB blocks at different locations, also at Q1T1.
MiB/s, MB/s and IOPS
Website throughput values use MiB/s: one mebibyte is 1,048,576 bytes. Existing app interfaces may label these same values MB/s. The website keeps the measured values and makes the unit explicit.
For 4 KiB operations, IOPS = MiB/s × 256. IOPS describes operations per second. Larger throughput and IOPS values mean more data or operations completed per second for that test.
Default contribution parameters
| Platform | Sequential test size | Random operations |
|---|---|---|
| iOS / Android | 512 MiB | 16,384 × 4 KiB |
| macOS / Windows | 1,024 MiB | 32,768 × 4 KiB |
The native engine uses platform-specific I/O and synchronization policies. Current submitted measurements record their workload version, cache mode and synchronization mode. Stress tests use longer sustained-write workloads and are separate from the four public ranking metrics.
How the results database works
Each public configuration is identified by Model + capacity + platform. Model text is preserved exactly as reported by the app. Capacity is the value reported for that configuration; it should not be assumed to be the drive manufacturer's advertised capacity.
Current submissions are stored individually and averaged on the server. Previously collected averages retain their original sample weights in a separate archive. When a configuration has current submissions, its public entry uses their mean; otherwise, it uses the imported aggregate. The two sets are not added together. This is a data aggregation rule.
Samples are test runs, not a count of unique physical devices. Repeated uploads of the same run identifier are not counted twice. Public Model pages link to all available capacities and expose the sample count and latest measurement date.
Which measurements are contributed?
Contributions require Submit Results to be enabled, a complete default-parameter test of internal storage, and an eligible physical-device release build without a cache warning. Custom-directory measurements and partial runs are not contributed. You can turn off future contributions in the app's settings.
When do new results appear?
The public API uses a cached snapshot, and website pages also use short-lived caches. New measurements normally appear on the website within about 25 minutes. The app has its own refresh schedule. Pages show when results were checked; an individual entry's measurement date is the date of its most recent included test.
If the service is temporarily unavailable, the website retains a saved snapshot and labels its date. It never turns a failed update into empty or zero-valued results.
Interpreting differences
Storage capacity, free space, operating-system behaviour, temperature and background work can affect measurements. Compare individual metrics for the workload you care about, and consider the number and dates of measurements alongside the speed. The site does not invent a combined performance score.
Close unnecessary background activity and use the same settings for repeated tests. For a longer write workload, use the app's stress test.