Baseline vs fix: two adjacent comparisons, one variable each
Same IMS co-verification twin, three runs. Every number below is read
from each run's frames.json, the same field the animations colour from.
All three runs
| Run | Window (us) | Targets |
Content | Deadline | Worst (us) | Margin (us) |
|---|
| baseline-2t | 8,000 | 2 | 3 stale, 1 degraded of 4 | in time | 8,600 | +9,400 |
| fix1-window-2t | 16,000 | 2 | 4 of 4 clean | in time | 12,700 | +5,300 |
| fix1-window-4t | 16,000 | 4 | 4 of 4 clean | 4 of 4 LATE | 18,900 | -900 |
A single pair spanning baseline to the four-target fix run moves
BOTH variables at once, and the only honest caption for it is "the same system at higher load
after the fix": it cannot say the fix caused the deadline miss, because the load changed in the
same step. Ordered as two adjacent pairs instead, each step isolates one cause.
Step 1
Only the fix changes
Changed: the fix (freshness window).
Held constant: target count (2), everything else.
Content 3 stale, 1 degraded of 4 → 4 of 4 clean. Deadline in time → in time,
margin +9,400 us → +5,300 us.
Step 2
Only the load changes
Changed: load (2 targets to 4).
Held constant: the fix (freshness window), everything else.
Content 4 of 4 clean → 4 of 4 clean. Deadline in time → 4 of 4 LATE,
margin +5,300 us → -900 us.
What this does and does not show. The freshness defect (stale data marked complete) is
cured by the fix at both target counts; content is clean in both fix runs. The deadline is held
at 2 targets and missed at 4. That is one system, one fix, two load points: it says the fix
works and the four-target deadline is a load problem the fix does not reach, not that a
differently-tuned fix could not also hold the deadline at four targets. Vendor numbers here are
invented for a fictional system; what is demonstrated is the method, not a finding about any
supplier.
Generated by
make_comparison_page.py from runs/baseline-2t-traces/frames.json, runs/fix1-window-2t-traces/frames.json and
runs/fix1-window-4t-traces/frames.json in innexis-vsi/demo-hwsw. Each embedded page is the same file served at
/flow/, opened directly above rather than summarised. See also the
frame-by-frame timeline, the same three runs read for WHEN
each event happened, the message flow, laid out by causal
order rather than shown as network traffic over time, and the
physical topology, what is actually wired to what.