Adding Up Both Full Paths

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

foundations

math-foundations

calculation-audit

edge-fog

ADA · CALCULATION AUDIT

Adding Up Both Full Paths

The chapter’s trace lists a 12 ms cloud kernel, an 80-120 ms WAN path, an 18 ms cloudlet kernel, and a 4 ms local hop — then says the slower kernel still wins. The kernel-only view favours the cloud by 6 ms, but the full loop favours the cloudlet by 70 to 110 ms. This audit totals both full paths to show why the acceptance gate belongs on the end-to-end path, not the datasheet kernel time.

Companion to the chapter Cloudlets: Local Compute Pools — every number here comes from that chapter.

See the relationship before changing it

The figure reads from left to right. The blue card is wan latency. The middle card applies the page rule. The green card is cloud loop time. Walk the arrows once: set the input, apply the rule, then read the result with its unit.

Walk the arrows. The faster cloud kernel still loses when the network path is long.

Derive the baseline in four named moves

1
Name the input. The chapter baseline is 80 ms.
2
Name the relationship. loop = 12 ms kernel + WAN latency
3
Substitute with units. 12 + 80 = 92.00 ms
4
Read the result. Keep the unit beside the value. Use it only inside the technical boundary on this page.

Predict, then change wan latency

Try Predict the direction of loop = 12 ms kernel + WAN latency. Test another wan latency, then compare cloud loop time.

Observe The faster cloud kernel still loses when the network path is long. Reset wan latency to 80 and compare cloud loop time.

Explain The faster cloud kernel still loses when the network path is long.

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 wan latency moves here. Field effects named in the technical boundary stay fixed.

TryThe chapter’s trace lists a 12 ms cloud kernel, an 80-120 ms WAN path, an 18 ms cloudlet kernel, and a 4 ms local hop — then says the slower kernel still wins. Use Check derivation.

ObserveThe displayed ledger resolves 12 ms, 80-120 ms, 18 ms, 4 ms, 6 ms at full precision. This audit totals both full paths to show why the acceptance gate belongs on the end-to-end path, not the datasheet kernel time. Check derivation shows this.

ExplainThe cloud's 12 ms kernel is faster than the cloudlet's 18 ms kernel, but adding 80-120 ms of WAN delay versus 4 ms locally makes the full cloudlet loop 70-110 ms faster. Check derivation confirms it.

Ada: The trace above lists a 12 ms cloud kernel, an 80-120 ms WAN path, an 18 ms cloudlet kernel, and a 4 ms local hop, then says the slower kernel still wins. That is exactly the kind of claim that looks wrong until you add the terms, so let me total both interaction paths.

Cloud full path. 12 ms kernel + 80 ms network = 92 ms at best; 12 + 120 = 132 ms at worst.
Cloudlet full path. 18 ms kernel + 4 ms network = 22 ms.
Compare. The kernel-only view favours the cloud by 18 - 12 = 6 ms. The full loop favours the cloudlet by 92 - 22 = 70 ms (best case) to 132 - 22 = 110 ms (worst case) — a 92 / 22 = 4.2x to 132 / 22 = 6.0x speedup.

The 6 ms kernel advantage is both real and irrelevant: the network term is an order of magnitude larger and arrives before every result. That is why the acceptance gate belongs on the measured end-to-end path, not the accelerator’s datasheet kernel time.

Technical boundaries
The path sum deliberately does not simulate WAN tail latency, queueing, contention, security handshakes, cache misses, or overlapping work; it adds the chapter's fixed local-hop, WAN, and kernel times.

Work the audit first, then check the displayed derivation.

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