DRAM & Memory Design · All levels
Scenario: Row Buffer Miss Storm
A production workload update changes address stride and suddenly drops row-hit rate across two hot channels. Average bandwidth is still acceptable, but p99 latency and ACT/PRE command pressure spike.
Scenario
A production workload update changes address stride and suddenly drops row-hit rate across two hot channels. Average bandwidth is still acceptable, but p99 latency and ACT/PRE command pressure spike.
OBSERVED METRIC
Row-hit rate collapse with p99 latency inflation under mixed read/write load.
45-MINUTE INTERVIEW FLOW
0-5: scope traffic and SLA context
5-15: map first failing DRAM transition
15-25: identify proving artifacts
25-35: propose bounded fix with owner
35-45: state validation matrix and rollbackCommon pitfalls
Blame PHY frequency first without proving row-buffer locality loss.
Tune FR-FCFS aggressiveness without checking fairness and starvation counters.
Use average bandwidth as success criteria while ignoring tail latency regressions.
Scenario debrief
Score candidate response on traffic framing, timing proof, mitigation boundedness, and regression discipline.
request stream -> controller policy -> DRAM timing behavior -> measured outcomelatency/bandwidth trendDebrief prompts
Which DRAM timing or queue behavior fails first in evidence?
Which smallest safe controller, PHY, or policy change addresses it?
Which benchmark + counter gate proves closure under production traffic?
Key takeaways
Always tie controller and PHY counter shifts to application latency and throughput outcomes.
Lock firmware timing profile, thermal condition, and DIMM state before comparing DRAM captures.
Common pitfalls
Chasing peak bandwidth while ignoring p99 latency and fairness tails.
Changing timing guardbands without separating SI noise from scheduling issues.
Declaring closure without reliability gates, fault injection, and regression replay.