Before we start, one word we lean on: a metric is just a measured number with units that answers one specific question. Latency answers "how soon?" (a time, in ns). Bandwidth answers "how much per second?" (a rate, in GB/s). Keep those two questions physically separate and most traps below disappear.
Three symbols we reuse everywhere. Before the first trap that names them, define them plainly:
W = bus width in bytes — how many bytes cross the bus in a single transfer (a 64-bit channel = 8 bytes).
f = clock frequency in Hz — how many times per second the clock ticks (e.g. 1600 MHz = 1.6×109 ticks/s).
N = number of channels — how many independent parallel buses the system has (dual-channel means N=2).
Peak bandwidth is built from these as BW=W×(2f)×N, where the 2f is the DDR "both edges" data rate.
Almost every trap below is a confusion between two different diagrams. Fix the pictures first, then read the questions.
Picture 1 — the timeline (latency). One request travels a fixed physical path: row activate → column read → first byte out. Its length is a time. Widening the bus does not shorten this arrow.
Figure s01 — Latency timeline. A single memory request drawn left-to-right in time. Three coloured blocks show the fixed physical stages row activate (teal) → column read (plum) → first byte out (orange). The double-headed arrow spanning them is L, the latency, measured in nanoseconds. The caption underneath reminds you that widening the bus does not shorten this arrow — latency lives here, in the sequence, not in the bus width.
Here L (latency) is the length of that arrow in seconds (we quote it in ns, where 1ns=10−9s).
Picture 2 — the flow rate (bandwidth). Once data is streaming, count how many bytes cross a line each second. That's a rate, B (bandwidth) in bytes/second. More lanes (channels), more edges (DDR ×2), wider bus (W) → more bytes per second — but each individual byte still spent time L getting to the line.
Figure s02 — Bandwidth as flow rate. Three parallel lanes (channels 0, 1, 2) each stream a row of byte-blocks past a dashed "count line". Bandwidth B is simply how many byte-blocks cross that line per second: adding lanes, adding clock edges, or widening each block all raise B. The bottom caption stresses that each byte still spent time L getting to the line — bandwidth is about throughput, not the arrival delay of any single byte.
Why nanoseconds carry a ×103 in the CL formula. Cycle time is Tclk=1/fclk in seconds. If we feed the data rate in MT/s (=2fclk, so a rate of 106 transfers/s), then tCL=data rate (MT/s)2CL comes out in microseconds (because "MT/s" already divides by 106). One microsecond is 103 nanoseconds, so we multiply by 103 purely to convert the units seconds→ns via the megatransfer scale. That single factor is a unit conversion, nothing physical.
False. Bandwidth grows by adding width, frequency, or channels; latency is the physical row-activate-then-column-read time inside the DRAM array. They are orthogonal — moving one lever does not move the other.
TF2. "DDR5 has lower latency than DDR4 because its numbers are bigger."
False (usually). DDR generations mainly raise the transfer rate (bandwidth). Absolute access time in nanoseconds has stayed roughly flat for decades — see DDR SDRAM generations and CPU memory wall.
TF3. "The '3200' in DDR4-3200 is the clock frequency in MHz."
False. 3200 is the data rate in MT/s (megatransfers/s). The actual clock is half that, 1600 MHz, because DDR moves data on both clock edges.
TF4. "CL16 always responds faster than CL18."
False. CL is counted in cycles, and a cycle's length depends on frequency. CL16 @ 3200 and CL18 @ 3600 both give 10 ns of real latency — you must convert cycles to time before comparing.
TF5. "Adding a second memory channel makes each individual request arrive sooner."
False. A second channel is a second parallel bus: it lets more requests be served per second (bandwidth up) but the per-request physical access path is unchanged (latency same). See Memory channels and interleaving.
TF6. "If peak bandwidth is 51.2 GB/s, a program that reads one byte, waits, reads the next, will see 51.2 GB/s."
False. Peak bandwidth assumes the bus is kept continuously busy. A serial one-at-a-time read spends most of its time waiting on latency, so it sees a tiny fraction of peak.
TF7. "Bandwidth and latency use the same units, so a big bandwidth cancels a big latency."
False. Bandwidth is bytes/second, latency is seconds — different units, different questions. They only meet through their product (bytes), via Little's Law.
TF8. "Row-buffer hits and misses affect bandwidth but not latency."
False. A row-buffer hit skips the row-activate step (see the shortened arrow in Picture 1), so it reduces latency for that access; misses pay the full activate cost. This is DRAM organization row buffer territory — latency depends on the access sequence.
Error: missing the ×2 for DDR — but also a hidden save. Recall W = bus width in bytes, f = clock frequency in Hz, N = number of channels. The clean way: BW = W × (data rate) × N, and 3200 MT/s already contains the ×2. If you instead used the 1600 MHz clock as f, you'd need the explicit ×2. Mixing "clock" into the "data rate" slot is the classic halving mistake.
SE2. "tCL=CL×data rate."
Error: multiplied instead of divided, and used the wrong rate. Latency is tCL=CL/fclk — cycles times cycle-lengthTclk=1/fclk, i.e. divide by frequency. In MT/s form: tCL=data rate2CL×103 ns, where the 103 converts the megatransfer-scaled microseconds into nanoseconds (see "The two pictures" section).
SE3. "To saturate a 50 GB/s bus with 60 ns latency you need about 50 outstanding requests."
Error: confused bytes with requests.Little's Law gives outstanding bytes=B×L, with B = bandwidth (bytes/s) and L = latency (s): 50×109×60×10−9=3000 bytes. The number of requests depends on how many bytes each request fetches (e.g. one cache line).
SE4. "Quadrupling channels from 1 to 4 cuts latency to a quarter."
Error: channels never touch latency. Bandwidth quadruples (×N is a bandwidth factor); latency is per-request and stays exactly the same.
SE5. "MT/s and MHz are the same thing for DDR."
Error. MT/s = 2 × MHz for DDR. 3200 MT/s corresponds to a 1600 MHz clock. Treating them as equal doubles or halves everything downstream.
SE6. "Since caches are fast, they raise the machine's memory bandwidth."
Error: caches mainly attack latency, not raw DRAM bandwidth.Cache hierarchy hides main-memory latency by serving hits quickly; it doesn't widen the DRAM bus.
WY1. Why are latency and bandwidth quoted as two separate specs on a RAM kit?
Because they answer different questions and scale from different physical causes — data rate from width/frequency, CL from the DRAM array's fixed access sequence — so no single number captures both.
WY2. Why does DDR get a ×2 factor at all?
Data is transferred on both the rising and falling edge of each clock cycle, so two transfers happen per cycle: effective rate =2f.
WY3. Why can two kits with different CL and frequency have identical real latency?
Higher frequency shortens each cycle by the same proportion that the extra CL cycles add, so the products CL/f come out equal in nanoseconds.
WY4. Why does keeping many requests "in flight" matter for reaching peak bandwidth?
Each request has fixed latency L; while one is in flight the bus could serve others. Only with enough concurrency — B×L bytes outstanding, where B is bandwidth (bytes/s) and L is latency (s), by Little's Law — does the bus stay busy and approach peak.
WY5. Why has latency barely improved while bandwidth soared over the decades?
Bandwidth is engineered by adding parallelism (width, edges, channels), which scales easily; latency is bounded by the physical charge/sense timing of a DRAM cell, which resists shrinking — this is the CPU memory wall.
WY6. Why is interleaving addresses across channels a bandwidth trick, not a latency trick?
Interleaving spreads consecutive accesses onto parallel channels so they overlap in time — raising throughput — but each single access still travels its own full-latency path.
WY7. Why does converting CL to nanoseconds require knowing the frequency?
Because CL counts cycles, and a cycle's duration is 1/fclk. Without the frequency, "CL16" is a count with no fixed time meaning.
EC1. What happens to achieved bandwidth when exactly one request is ever outstanding at a time?
It collapses toward (bytes per request)/L — pure latency-bound behaviour — which can be a small fraction of peak, no matter how wide the bus.
EC2. If latency were zero, would you still need bandwidth?
Yes — even with instant first-byte arrival, moving a large block still takes bytes ÷ rate. Bandwidth governs bulk transfer regardless of the initial delay.
EC3. If bandwidth were infinite, would latency stop mattering?
No — the first byte of any dependent access still waits the full latency L. A dependency chain (each read needs the previous result) is bounded by latency, not bandwidth.
EC4. What is the achieved bandwidth of a single access to a byte that just missed the row buffer?
Effectively it's dominated by latency: one byte after a full activate → read delay. Peak bandwidth only appears when a long burst streams out of an already-open row.
EC5. Two channels, but the workload only ever touches addresses mapped to channel 0 — what bandwidth do you get?
About half of peak. Channels only add throughput if traffic is spread across them; an unbalanced access pattern leaves the second channel idle. See Memory channels and interleaving.
EC6. CL is the same number of cycles on two kits, but one runs at double the frequency — which has lower nanosecond latency?
The higher-frequency kit: same cycle count but each cycle is half as long, so tCL=CL/fclk is halved.
EC7. A single-channel and a dual-channel kit have identical CL and frequency — do they have identical latency?
Yes, identical latency. The dual-channel kit only offers more bandwidth; per-request access time is untouched by channel count.
