Write Recovery and Turnaround

Write Recovery and Turnaround: tWR, tWTR_S, tWTR_L, tRTP

Reads get most of the attention in RAM-tuning discussions because CL is the headline number on every box, but the write side has its own set of minimum delays — and getting them wrong is just as capable of causing instability, just less visible in casual use because writes are less latency-sensitive than reads in most workloads.

tWR — Write Recovery Time

Minimum time after the last data of a write burst before a PRECHARGE may be issued to that bank. Writing is the reverse of the read/sense process described in Primary Timings CL tRCD tRP tRAS tRC: incoming data has to actually be driven into the storage capacitors through the sense amplifiers, which takes real time to complete. Precharge that bank before tWR elapses and you risk closing the row before the write finished landing in the cells — a real data-corruption path, not merely a performance one. In this project's reference kit, tWR is a flat 15ns across every module regardless of density or rank — it's a comparatively stable, low-variance timing across the DDR4-3200 generation of parts.

tWTR_S / tWTR_L — Write to Read turnaround

Minimum delay after a write burst before a READ command may issue — again split into same-bank-group (_S, tighter) and different-bank-group (_L, looser) cases for the same reason described in Bank Group and Activation Timings. The underlying cause here is specific to DDR's data bus: DDR4's DQ (data) bus is half-duplex — it carries either outbound write data or inbound read data, never both at once. Switching direction costs real time: the write path's internal buffers need to fully drain, and the bus itself needs an electrical turnaround period before the opposite direction can drive it cleanly. Skipping this is a bus-contention risk, not just a stall.

tRTP — Read to Precharge

Minimum time after a READ command before a PRECHARGE may issue to that bank — the read-side mirror of tWR. The sense amplifiers need to finish their read-and-restore cycle (see the "destructive read" note in Primary Timings CL tRCD tRP tRAS tRC) before it's safe to close the row.

Why spd-matchtable treats tRTP as inferred, not measured

DDR4's base SPD timing block does not include tRTP as an explicit byte field the way it does CL/tRCD/tRP/tRAS/tRC/tRFC/tFAW/tRRD/tCCD_L. Real-world DDR4-3200-class parts commonly converge on a tRTP around 7.5ns regardless of vendor, which is where this tool's ~7.5ns heuristic in the "Suggested starting point" cheat-sheet comes from — but it is explicitly a generic industry-common estimate, not something read from this specific module's SPD, and the tool's own output labels it that way (tRTP~=, with the ~ doing real work) rather than presenting it with the same certainty as a directly-measured value. See Command Rate and tCWL for the rest of the values SPD doesn't encode and how each is estimated.