docs: U64E 1/8/48 MHz e2e sweep + device as a table column

[JC-000]

Measured clock sweep on the U64E at master 2ceb5b1, UCI/REU profile, plus a structural fix to how the e2e wall-clock table identifies devices.

Measurements

device	profile	1 MHz	8 MHz	48 MHz	64 MHz
U64E	REU @ 2ceb5b1	1157.7 s	196.5 s	80.8 s	n/a — no enum

Handshake + GET measured C64-side from run_prg, not whole-script wall-clock. One clean BACKEND=uci build reused across all three runs, so clock is the only variable. All three PASS, each with server-side evidence — the listener decrypted the full GET / HTTP/1.1 with no TLS error, which also exercises the server_result.json assertions merged in #82.

Reproduces the two published U64E figures closely: 80.8 s against a documented 82.1 s at 48 MHz (-1.6%), and 1157.7 s against 1142.9 s at 1 MHz (+1.3%).

Fit

T(f) = D + C/f gives D = 58.5 s, C = 1099 MHz·s, residuals ≤ 0.69% across a 48× clock range.

• The ~58 s floor against the documented 48.2 s REU-profile verify floor localises ~10 s of clock-invariant non-verify cost — UCI firmware round-trips and network latency, which turbo does not touch.
• Diminishing returns are stark: 1→8 MHz (8× clock) bought 5.9×; 8→48 MHz (6× clock) bought 2.4×.
• Extrapolated 64 MHz: 75.6 s — which is the quantitative case for the REU profile being the wrong choice above ~7 MHz.

Structural fix

The e2e table was captioned (C64U, local listener) with 48/64 MHz columns. A U64E row added there would have silently inherited the C64U label, and the REU-profile device delta is 10-13% — large enough that a mislabelled row misleads rather than merely confuses. Device is now a column, and 1/8 MHz columns exist.

Not delivered

The requested 64 MHz point. It exists only on the C64U, which was offline: 10.53.21.158:80 times out, no ARP entries on 10.53.21.x, and the bench host is on 10.43.23.85 — a different subnet. Confirmed offline by the owner rather than assumed.

🤖 Generated with Claude Code

[JC-000]

Second commit: onchip sweep added, and a claim from the first commit retracted.

The onchip-profile sweep completed, so the table now carries both profiles on the U64E:

device	profile	1 MHz	8 MHz	48 MHz
U64E	REU	1157.7 s	196.5 s	80.8 s
U64E	onchip	2120.7 s	264.5 s	45.5 s

Fits: REU D=58.5 s, C=1099, residuals ≤0.69%. Onchip D≈0.5 s, C=2120, residuals ≤1.92%. Measured e2e crossover 17.6 MHz, against the independently-derived verify-only ~18 MHz.

Retraction

The first commit claimed the ~58 s REU floor minus the documented 48.2 s verify floor localised "~10 s of clock-invariant non-verify cost". That is wrong, and the onchip sweep is what shows it: a genuinely clock-invariant cost would appear in both profiles' floors, and the onchip floor is ~0.5 s. Forcing D=10 on the onchip points throws the 8 MHz prediction off by 16%.

The correct reading is tidier. UCI's post-ServerHello drain is 16 polls at ~40 ms ≈ 0.64 s — essentially exactly the onchip floor. So the fixed network cost is sub-second, and the REU profile's 58 s floor is almost entirely DMA. The original error was subtracting a verify-only floor from an e2e floor measured under different conditions; the two aren't commensurable.

Also now flagged in the text: the onchip D is poorly conditioned. At 48 MHz the C/f term is ~99% of the total, so D is fitted from the remainder and should be read as "under ~2 s" rather than 0.5 s. That is the same ill-conditioning the project already documented for 2-point fits, and it is worth stating rather than quoting a spuriously precise floor.

What makes the model credible

The onchip fit was built from the 8 and 48 MHz points and used to predict 1 MHz at 2104 sbefore that run existed. It measured 2120.7 s — +0.8% over a 48× extrapolation. A crossover prediction inherits that credibility; a curve fitted to noise would not survive that test.

Still to land on this branch: a crossover probe at 16 and 20 MHz on both profiles (the tightest bracket the CPU-speed enum allows around 17.6 MHz — there is no 18), and a no-REU run to test whether an inactive REU affects anything.