Bandwidth counters must agree on definitions before any comparison. Beats times bytes per beat is bandwidth; valid toggles alone are not.
Warm up caches, fix the sampling window across hops, and keep coherency and prefetch bytes visible instead of folding them into demand.
Rule | Practice | Why |
|---|---|---|
Bytes, not beats | Multiply beats by bytes per beat | Narrow beats inflate toggle counts |
Same window | Synchronized start and stop at every hop | Skewed windows fake loss or gain |
Warmup excluded | Drop the first N transactions | Cold caches distort steady state |
Split traffic classes | Demand, prefetch and snoop bytes apart | Pollution hides inside totals |
Walk the hierarchy in order and stop at the first queue whose latency rises with demand. Everything downstream of it is starved, not broken.
Build the per-hop waterfall under one synchronized window.
Plot queue latency against offered load at each hop and mark the knee.
Name the first hop past its knee as the bottleneck.
Confirm with the Little check: needed outstanding above depth proves saturation.
Fix that hop only, then re-measure the whole path.
Write-drain threshold trades read blockage against turnaround cost. Sweep it with latency guards, and accept only settings that hold the tail.
Drain threshold | Sustained (GB/s) | p99 read (ns) | Verdict |
|---|---|---|---|
Drain at 8 | 112 | 180 | Reads safe, turnarounds heavy |
Drain at 32 | 118 | 210 | Accept: best bytes under 250 ns guard |
Drain at 128 | 121 | 320 | Reject: breaks the 250 ns guard |
The sweep above is illustrative for a 70 percent read and 30 percent write mix. QoS needs the same guards: read bursts go first, but aging or weighted shares stop starvation, and p95/p99 plus starvation counters prove it.
The NoC, if it is first past its knee. The controller may simply be starved by it.
No. The guard decides, so drain-at-32 at 118 GB/s and 210 ns is the accepted point.