A Short DRAM Access Time Does Not Remove a Refresh Wait

Separate refresh duration from refresh cadence

A memory offer may give a short CAS-derived interval and still leave a request waiting for its target bank. The missing question is whether that bank is available when the request needs it. The related CAS timing article explains the clock conversion; refresh adds a separate availability question.

Micron's DDR5 new-features whitepaper explains that banks targeted by refresh must first be idle and cannot perform reads or writes during the operation. It identifies tRFC with the refresh duration and tREFI with the average interval between refresh commands. Duration tells you how long an operation occupies its targets; cadence tells you how often refresh is required on average.

Microchip's PolarFire SoC MSS documentation, edition en-US-21, corroborates those definitions in its DDR4 timing table: tRFC is the time needed to complete a refresh operation, while tREFI is the average time between refresh commands. That table is DDR4 controller documentation, not a DDR5 server specification. An average interval alone does not establish the exact start time of each refresh or the wait experienced by an arriving request.

References: [RW][RT]

Read all-bank and same-bank at the bank boundary

Micron's public DDR5 comparison lists all-bank and same-bank refresh. Its REFsb description specifies a bank in each bank group. Same-bank therefore does not mean that only one bank across the whole device is involved: the same bank is targeted across the bank groups. All-bank refresh targets all banks in the addressed DRAM scope.

That distinction changes which banks must be unavailable together. Micron's whitepaper explains that banks outside the same-bank refresh target can remain active, subject to other timing constraints. Work for a bank outside that target may therefore remain eligible, but eligibility alone does not establish controller scheduling, simultaneous transfers or useful throughput.

Keep this bank-level question separate from the number of populated processor memory channels. A DDR5 feature listing also does not establish which refresh mode an offered server actually uses. The related channel-population article handles the configuration evidence without turning module or channel counts into a refresh-performance result.

References: [RM][RW]

REF-W80: equal work, different arrival times

Consider a deliberately fictional timing model for one target bank. Time t is measured in nanoseconds. Stipulate that refresh blocks the bank throughout 0 <= t < 80 ns. Further blocked windows start at 1000 ns, 2000 ns and so on, each lasting 80 ns. This perfectly periodic schedule is an assumption of the example, not an interpretation of every real tREFI schedule.

Replace every other service and queue effect with a constant 20 ns of remaining work after a request becomes eligible. That invented allowance includes all remaining work in one lump; it is not a CAS value or a DRAM command sequence. In particular, becoming eligible at the end of refresh is not a claim that a READ can immediately be issued without any required activation or other timing.

Request A arrives at t = 20 ns and needs the refreshing bank. It waits until t = 80 ns, giving 80 - 20 = 60 ns of refresh wait. Its stipulated remaining work then takes 20 ns. Completion is at t = 100 ns, so elapsed time from arrival is 100 - 20 = 80 ns.

An independent request B arrives at t = 120 ns. No refresh window overlaps its stipulated service: it has no refresh wait, its remaining work takes 20 ns, and it completes at t = 140 ns. Elapsed time is 140 - 120 = 20 ns. No other overlap or interference is stipulated for either request.

Both requests have the same 20 ns remaining-work allowance. Their different elapsed times come entirely from arrival relative to the blocked window. Quoting that allowance alone would conceal A's 60 ns wait. In this model, completion time equals arrival time plus refresh wait plus remaining work; the example supplies no hardware measurement.

An 8 percent blocked fraction does not rank applications

Over one complete 1000 ns period in REF-W80, the target bank is blocked for 80 ns. Its blocked-time fraction is 80 / 1000 = 0.08, or 8 percent. This describes time on the fictional bank's schedule.

It does not follow that an application loses 8 percent of its bandwidth, slows by 8 percent, or has an 8 percent chance of a delayed request. Those conclusions need information absent from the fraction: which banks requests need, when they arrive, what other work is ready and which delays affect application completion. The example deliberately gives A a refresh wait and B none under exactly the same blocked fraction.

The distinction also explains why neither duration nor cadence should be read alone. Duration describes one blocked window; cadence contributes to how those windows recur. Request arrival determines the residual wait within a particular window. Even knowing both timing parameters would leave actual scheduling and workload effects unresolved. The perfectly periodic model makes that reasoning visible without proposing a refresh setting.

Ask what the memory offer actually establishes

Suppose two otherwise comparable GPU-server offers advertise different CAS-derived intervals, and the seller attributes faster host preprocessing to the shorter one. The CAS comparison can establish a difference in that component when its paired operating inputs are known. It cannot establish whether preprocessing requests encounter refresh, how long they wait, or whether those waits change pipeline completion.

Keep the complete server identity, CPU and module configuration, supported population and actual operating timing together. For a refresh-specific claim, ask the platform owner for the applicable device and controller documentation, the refresh mode used by that configuration, the associated duration and average-interval definitions and values, and evidence of actual behavior supporting the claim. A generic DDR5 feature list cannot fill those configuration-specific fields.

Then request application comparison evidence on the offered configurations. Retain the workload and software versions, data size, host-memory configuration and measured preprocessing or pipeline result. If a report attributes a difference specifically to refresh, ask what observations support that attribution and how other configuration differences were accounted for. A completion-time difference by itself does not identify its cause.

A useful buying conclusion may be narrower than a performance ranking: the offers have a documented nominal timing difference, while their refresh-related workload effect remains unproven. Keep that unresolved question with the platform and application owners. Use the linked CAS and channel-population guides for their respective component and configuration checks; neither substitutes for the missing workload evidence.

Carry the selected equipment into the physical scope

Once the platform owner has selected the supported complete system, use that equipment identity in the physical project brief. Leviathan's Rack Assembly & Preparation service covers discussion of separately agreed receiving, preparation, mounting, physical interconnections and handoff records around supplied equipment.

The related project inquiry is a route to share a nonconfidential equipment brief, approved configuration revision, factory-complete state, proposed location, receiving arrangements and permitted remaining physical tasks. Memory qualification and application-performance acceptance remain with the appointed platform and application owners. The inquiry defines the physical package and records for the selected system.