The 119 ms Path and Its Fragile Margin

The 119 ms Path and Its Fragile Margin

Ada re-derives this chapter’s own numbers step by step, at full precision

foundations
math-foundations
calculation-audit
networking-core
Ada ADA · CALCULATION AUDIT

The 119 ms Path and Its Fragile Margin

The chapter’s crosswalk example chains five hop delays into a 119 ms end-to-end path against a 500 ms safety budget — comfortable, with 381 ms to spare. Yet one careless protocol choice can erase most of that headroom. This audit totals the hops and prices the “skip QoS” mistake to expose how fragile the 119 ms margin really is.

Companion to the chapter Packet Journey Adventure Game — every number here comes from that chapter.

See the relationship before changing it

The figure reads from left to right. The blue card is peering queue delay. The middle card applies this page's rule. The green card is end-to-end delay. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

The retained audit below checks several chapter fixtures. This model keeps those stated values fixed and changes only peering queue delay, so the numeric fixture does not switch without explanation.

Peering queue delay changes end-to-end delay An input card leads through the rule path delay = 89 ms fixed hops + peering queue to the end-to-end delay result. INPUT PAGE INPUT APPLY THE RULE predict calculate check units OUTPUT RESULT
Walk the arrows. One queue delay adds directly to every other hop and spends the end-to-end safety margin.

Derive the baseline in four named moves

  1. 1

    Name the input. The chapter baseline is 30 ms.

  2. 2

    Name the relationship. path delay = 89 ms fixed hops + peering queue

  3. 3

    Substitute with units. 89 + 30 = 119 ms

  4. 4

    Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change peering queue delay

Try Predict the direction of path delay = 89 ms fixed hops + peering queue. Test another peering queue delay, then compare end-to-end delay.

30 ms
Chapter baseline
End-to-end delay

Observe One queue delay adds directly to every other hop and spends the end-to-end safety margin. Reset peering queue delay to 30 and compare end-to-end delay.

Explain One queue delay adds directly to every other hop and spends the end-to-end safety margin.

Check yourself

What should you do before trusting a moved-control result?
Answer: Predict its direction, apply the shown relationship, keep the units, and reset to the worked baseline.
What does this small model leave out?
Answer: Only peering queue delay moves here. Field effects named in the technical boundary stay fixed.

Honesty note. This teaching model changes only peering queue delay. It is not a field prediction.

TryRecompute 7 + 25 + 55 + 17 + 15 = 119 ms end to end.
ObserveTrack Safety margin: 500 - 119 = 381 ms of headroom, and 119 < 500, so the design passes.
ExplainExplain Remaining margin: 500 - 289 = 211 ms, i.e. 211 / 500 = 0.422 = 42% of the budget.

Ready: use the stated baseline inputs, then compare each displayed result.

Ada: The crosswalk example adds five hop delays to 119 ms against a 500 ms safety budget, then warns that one careless protocol choice erases most of the headroom. Let me total the hops, confirm the margin, and price the “skip QoS” mistake.

Summing the five hop totals:

  • 7 + 25 + 55 + 17 + 15 = 119 ms end to end.
  • Safety margin: 500 - 119 = 381 ms of headroom, and 119 < 500, so the design passes.

The middle hop is worth checking because it mixes three delay types — 10 (propagation) + 0.12 (transmission) + 14.88 (queueing) = 25.00 ms — which shows queueing, not distance, dominates that leg. Now the counterfactual where the alarm is sent best-effort instead of expedited, so the peering queue grows from 30 ms to 200 ms:

  • New total: 119 - 30 + 200 = 289 ms.
  • Remaining margin: 500 - 289 = 211 ms, i.e. 211 / 500 = 0.422 = 42% of the budget.

The design meaning is that a single per-hop decision moves the whole end-to-end result: one un-prioritised queue turned 381 ms of comfort (381 / 500 = 76% of budget) into 211 ms (42%), still passing but no longer safe against a second bad hop. That is why the chapter budgets for worst case — the delays are additive, so headroom that looks generous at the average collapses quickly when even one hop is left to best-effort handling.

Every number above is taken from the chapter’s own material and re-derived step by step.

Technical boundaries. This path audit deliberately does not simulate queueing, jitter, route changes, or correlated link loss. End-to-end delay and margin are sums of the fixed hop latencies and link-budget terms selected in the chapter scenario.