Infrastructure estimates
Why does high IOPS not guarantee fast file transfers?
Tools to use
A large IOPS figure looks fast, but many small reads and a sequential file transfer are different workloads. IOPS counts operations per second; multiply by bytes per operation to get throughput. Use this calculator to align comparison assumptions, not to predict a device's measured performance.
Calculate 10,000 IOPS at 4 KiB
10,000 × 4 × 1024 = 40,960,000 byte/s
40,960,000 ÷ 1024² = 39.0625 MiB/sChoose IOPS-to-throughput, enter 10000 IOPS and average size 4 KiB. The result is 40960000 byte/s or 39.0625 MiB/s. The operation count is not itself MB/s: the 4 KiB condition connects the two. Enter the count without a thousands separator and note the size field's KiB unit.
The same rate is 40.96 decimal MB/s. The difference from 39.0625 reflects units, not changed performance. Convert MB/s and MiB/s to a common unit before comparing. A bare 'about 40' hides the basis of the comparison.
At the same rate, 64 KiB moves sixteen times as much
10,000 IOPS × 64 KiB = 625 MiB/s
64 ÷ 4 = 16
625 ÷ 39.0625 = 16Keep 10000 IOPS and change the size to 64 KiB: the result is 625 MiB/s, sixteen times as much. This does not establish that the same SSD sustains 10000 IOPS at both sizes. The calculation assumes the rate you entered; measurement must establish whether it is achievable.
Do not rank one product's maximum small-I/O count directly against another's large-I/O throughput. Align read/write, sequential/random and outstanding-request conditions too. Variables absent from this calculator have not been evaluated by its numeric output.
Work backwards from a throughput target
100 MiB/s ÷ 4 KiB = 25,600 IOPS
100 MiB/s ÷ 64 KiB = 1,600 IOPSIn reverse mode enter throughput 100 MiB/s and size 4 KiB: 25600 IOPS. At 64 KiB it is 1600 IOPS. The same data rate requires different operation counts depending on granularity, which is a useful initial check when considering batched reads.
Reading larger chunks can also fetch unnecessary data, increasing total bytes while reducing operation count. Larger average size is not itself the goal. Observe useful data, latency and cache behaviour; the reverse calculation does not guarantee batching makes the application faster.
Use bytes and operations from the same interval
Average size is total bytes divided by total operations over the same interval. Pairing read-only bytes with combined read/write operations understates it. Avoid mixing maxima from different times. Match population, observation window and counting layer.
One application read need not equal one storage-counted I/O: requests may be split or merged. For a cloud IOPS allowance, check the service's counting rules. This generic calculator does not automatically implement provider-specific splitting or billing conventions.
Use the result to organize possible bottlenecks
Systems can have both operation-rate and byte-rate limits. A calculated 625 MiB/s cannot be sustained through a lower throughput ceiling; small I/O may instead hit the operation limit first. Put both constraints in comparable units to identify what to investigate next.
Report '39.0625 MiB/s assuming sustained 10000 IOPS at average 4 KiB', and label measured values, published maxima and hypothetical inputs separately. A short statement of assumptions prevents a simple conversion being mistaken for a hardware guarantee.