Peak bandwidth is rate × width ÷ 8, and you never get it. This subtracts refresh, bus turnaround and row misses to give what actually reaches the host — with read and write split out, real latency in nanoseconds, and every overhead shown separately so you can see which one to attack.
Runs entirely in your browser. Nothing is uploaded, stored, or sent anywhere.
Every memory bandwidth calculator multiplies data rate by bus width and divides by eight. DDR4-3200 on a 64-bit channel gives 25.6 GB/s, and that figure is correct in exactly the sense that a car's top speed is correct. It is what the bus could carry if the DRAM never refreshed, never turned the bus around, and never had to open a different row.
All three of those happen constantly, and together they typically remove 15–40 % of the peak before anything reaches the host. This tool subtracts them and shows each one separately, because the interesting question is never "what is peak" but "which overhead is eating my budget".
Refresh is deterministic and you cannot fix it. Every DRAM row must be refreshed, and during tRFC the rank cannot serve traffic. The cost is simply tRFC divided by tREFI. On DDR4 that is around 350 ns every 7.8 µs, so about 4.5 %. On DDR5 it is worse — roughly 295 ns every 3.9 µs, about 7.6 % — which surprises people who assume each generation improves everything. Above 85 °C the refresh interval halves and the cost doubles, so a thermally constrained design pays twice.
Bus turnaround is the one that is really about your controller. DQ is bidirectional: the same wires carry reads and writes, and reversing them costs dead cycles while drivers settle. A perfectly interleaved 50/50 read/write stream would spend more time turning around than transferring. Real controllers avoid this by batching — buffering writes and draining them in groups — which is why the controller selector matters so much. Set the queue depth to 1 and watch the efficiency collapse; that is what an in-order controller does.
Row misses are about your access pattern. A DRAM bank holds one open row. Hit it and you pay CAS only; miss it and you pay precharge plus activate first. Sequential streaming hits the open row almost every time. Pointer chasing and hash lookups miss almost every time, and that is why the random preset drops so far — not because the memory is slower, but because you are paying tRP+tRCD for every 64 bytes.
The queue depth selector is the one worth playing with, because it separates two questions that get confused constantly: is the memory too slow, or is the controller failing to use it?
A controller with a queue depth of one has no choices to make. It issues what arrives, in the order it arrives. It cannot batch writes, so every read-to-write alternation costs a full turnaround. It cannot look ahead for requests that hit an already-open row. It cannot keep several banks busy so that one bank's precharge hides behind another's transfer. Take the same DRAM and the same access pattern, move from queue depth 1 to 32, and the effective bandwidth typically moves by a factor you would otherwise have gone looking for in a faster speed grade.
This matters for a real decision. If your measured bandwidth is far below the figure here at a realistic queue depth, the problem is upstream of the memory — not enough outstanding transactions from the masters, an interconnect that serialises, or a DMA engine issuing one descriptor at a time. Buying a faster grade will not fix any of those. All three of the scheduler's advantages saturate, which is why the model shows diminishing returns past about 32: reordering can only exploit locality that is already in the stream.
Set the pattern to random 64 B and compare DDR4 with RLDRAM 3. The DDR part collapses, because every access pays tRP+tRCD and there is no locality to hide behind. RLDRAM barely notices: it has sixteen banks and a tRC around 15 ns against DDR4's forty-something, and it was designed for exactly this. That is the whole product rationale, and it is visible in the overhead table rather than needing to be asserted.
QDR-II+ and QDR-IV go further. They are SRAM, so there is no refresh and no row buffer at all, and they have separate read and write ports — so the turnaround term is not reduced, it is zero. Efficiency sits near 100 % at any pattern and any queue depth. You pay for that in cost per bit and in density, by a wide margin, which is why it survives only where the worst case matters more than the average: line-rate packet lookup, where a refresh collision would be a dropped packet.
At the other end, HyperRAM and OctaRAM give you DRAM density over eight or sixteen pins, for microcontrollers with no room for a DDR PHY. Sequential throughput is respectable and the initial access latency is long, which makes them good for framebuffers and audio buffers and poor for anything that chases pointers.
The DQ bus is symmetric: peak read bandwidth and peak write bandwidth are the same number, because they are the same wires. Anyone quoting different peak figures for read and write on a DDR interface is quoting a controller or a benchmark, not the interface.
What differs is the mix. A pure read stream and a pure write stream are both efficient; it is the combination that costs, because that is what forces turnarounds. This is why a memcpy benchmark, which reads and writes in equal measure, reports so much less than the datasheet, and why read-only streaming benchmarks look so much better than real workloads. Writes also carry a recovery time (tWR) before the bank can be precharged, and most controllers prioritise reads because a read usually has a core stalled behind it while a write does not.
This is the most useful thing to take away from the speed-grade table. Compare the CAS latency in nanoseconds — not in clocks — across generations:
Bandwidth has gone up roughly eightfold since DDR3. CAS latency in real time has not improved at all, and at JEDEC bins it has gone slightly backwards. Every generation raises the clock and raises the latency in clocks by about the same factor, because the underlying DRAM array physics has not changed. If your workload is latency-bound rather than bandwidth-bound, a faster memory generation will do very little for you, and that is worth knowing before you respin a board for it.
The same point explains HBM. An HBM3 stack delivers over 800 GB/s against a DDR5 channel's tens of GB/s, but its latency in nanoseconds is comparable. HBM buys enormous parallel bandwidth through a 1024-bit interface; it does not buy a faster individual access. Choose it for throughput, never for latency.
It is a first-order budget with every term visible and editable, not a cycle-accurate DRAM model. It does not simulate the scheduler, address mapping, bank groups, tFAW limits on the activate rate, or refresh colliding with a burst in flight. Those matter, and for a design that lives or dies on memory efficiency you want a real cycle model. What this gives you is the shape of the answer and, more usefully, which term to attack — which is usually all you need to decide between a wider bus, a faster grade, or a better controller.
The numbers here also assume the interface is the bottleneck. Frequently it is not: the PDN feeding a DDR interface has to survive the transient of every DQ line switching at once, and a marginal channel at DDR5 rates will fail long before efficiency becomes interesting. If you are getting the bandwidth but the link is unreliable, the timing budget and impedance tools are where to look. For the interface that carries this bandwidth onward to a host or accelerator, the bus bandwidth calculator does the same subtraction for PCIe, CXL, Ethernet and the rest.
Each of these runs entirely in your browser. Nothing is uploaded, stored or sent anywhere, and none of them needs an email address.
See all 49 engineering tools →
We add tools here fairly often and write up the things worth writing up — a stackup that behaved oddly, a standard that turned out to be obsolete, a calculator that was quietly wrong. Join and you get told when something new lands.
One email a month at the very most, and usually less. No drip sequence, no sales cadence, no sharing your address with anyone. Unsubscribe whenever you like.