An interval is time between events; rate is events per unit time. If the selected part/mode requires more frequent refresh at a higher temperature, its allowed interval becomes shorter, not longer. Exact thresholds and supported modes must come from that device’s specification; no universal temperature threshold is assumed here.
Extend the existing one-rank example with an explicitly hypothetical second supported schedule: keep a 350 ns unavailable interval but change the average interval from 7,800 ns to 3,900 ns. Assume non-overlapping refresh occupancy and ignore all other losses only for this arithmetic.
Refresh interval and refresh rate move in opposite directions — worked trace
Illustrative isolated example; not measured silicon behaviour.
Illustrative schedule | Refresh rate | Rank occupancy |
|---|---|---|
One event per 7,800 ns | About 128,205 events/s | 350/7,800 = 4.49% |
One event per 3,900 ns | About 256,410 events/s | 350/3,900 = 8.97% |
Interpretation | Rate doubles when interval halves | Workload throughput still depends on overlap and other ranks |
The interval went down but the event rate went up. In this fixed-tRFC example rank occupancy also doubled; neither phrase alone specifies measured workload bandwidth.
DRAM cells leak charge, so the controller must meet the selected device's refresh requirements. tREFI is the average interval between refresh commands, not the time in which every row is refreshed. For a concrete DDR4 example, Frontgrade UT8SD4MQ2G72 datasheet version 0.0.3, page 47, specifies 8,192 refresh cycles over 64 ms at 0–85°C, with tREFI approximately 7.8 µs. A single refresh command covers only part of that overall work.
tRFC is the refresh recovery interval, a different timing parameter from tREFI. Which banks or ranks are unavailable depends on the selected device and refresh mode. Do not assume a per-bank refresh option exists just because a device is DDR4. Any refresh postponement must stay within its specified limits; the controller cannot defer required refresh indefinitely.
Three refresh timescales, three different questions
Definitions for the existing selected-device example. Numerical part limits remain in the surrounding cited lesson; this table is not drawn to time scale.
Timescale | Meaning | Do not confuse it with |
|---|---|---|
tRFC | Refresh recovery interval for the selected command/mode | The average interval between refresh commands |
tREFI | Average refresh-command interval under the selected schedule | One continuous rank-unavailable duration |
Full refresh window | Window over which the required set of refresh work is covered | One uninterrupted tRFC-like stall |
What to notice
Refresh commands and recovery intervals are distributed over the full window.
Bank/rank unavailability depends on the actual part and mode; the names alone do not establish channel-wide throughput loss.
No. It is the window for completing the required refresh work, not one recovery interval or a single continuous stall.
Estimate refresh occupancy from the selected mode's tRFC and refresh schedule; measure workload delay separately.
All-bank refresh makes the selected rank unavailable; other-rank scheduling depends on the controller and shared channel constraints.
Low-power self-refresh has its own entry/exit latency cost.
A row hit finds the requested row already active, so the controller can schedule a column READ or WRITE when timing permits. An idle bank has no active row and needs ACTIVATE before the column command. A row conflict finds a different row active in that bank and therefore needs PRECHARGE, ACTIVATE and then the column command, subject to the selected device's timing values.
Sequential requests can create row hits when address mapping and row boundaries keep them in the same active row. Strided or random requests may create conflicts, but bank interleaving, scheduler reordering and the exact address map determine the result. Measure command counts and latency for the actual replay rather than assigning generic nanosecond ranges.
Refresh occupancy is not a measured bandwidth prediction
Illustrative single-rank all-bank model: one 350 ns unavailable interval per 7,800 ns interval, no overlapping refresh intervals. Use these only for arithmetic, not as DDR4 part limits. Assume 3,200 MT/s and a 64-bit payload interface, excluding ECC bits.
Quantity | Calculation | Interpretation |
|---|---|---|
Peak payload ceiling | 3,200 million transfers/s × 8 bytes = 25.6 GB/s | Decimal GB/s; already uses transfers/s, so do not multiply by two again. |
Rank refresh occupancy | 350 / 7,800 ≈ 4.49% | Unavailable share under this isolated schedule. |
Refresh-only ceiling | 25.6 × (1 − 350/7,800) ≈ 24.45 GB/s | An upper bound within this simplified model, not expected workload throughput. |
Measured useful traffic | Useful accepted bytes / elapsed seconds | Includes scheduling, queueing and traffic effects at the stated measurement boundary. |
What to notice
Other ranks may do useful work while this rank refreshes; channel-wide loss need not equal this rank's occupancy.
Row-conflict work and direction changes can overlap other constraints. Subtracting each reported percentage independently can count the same time twice.
No. Under the simplified model refresh alone reduces the ceiling to about 24.45 GB/s. Investigate command timing, row/bank mapping, traffic mix, queueing and measurement boundaries without treating those effects as automatically additive.