From 120458d7a32ee8f612493d66fe4c947f90661d0d Mon Sep 17 00:00:00 2001 From: JC-000 <3798556+JC-000@users.noreply.github.com> Date: Thu, 13 Aug 2026 09:20:48 -0500 Subject: [PATCH] docs: U64E 1/8/48 MHz e2e sweep + make device a table column MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds a measured clock sweep on the U64E (10.43.23.81), UCI/REU profile, at master 2ceb5b1: 1 MHz 1157.7 s, 8 MHz 196.5 s, 48 MHz 80.8 s (handshake + GET, C64-side from run_prg). One clean BACKEND=uci build reused across all three runs so clock is the only variable; all three PASS with server-side evidence. Restructures the e2e wall-clock table so the device is a COLUMN rather than a caption. The previous table was captioned "(C64U, local listener)" with 48/64 MHz columns, so any U64E row added to it would have silently inherited the C64U label — and the REU-profile device delta is 10-13%, large enough that a mislabelled row misleads. Fit T(f) = D + C/f over the sweep: D = 58.5 s, C = 1099 MHz*s, residuals <= 0.69% across a 48x clock range. The ~58 s floor against the documented 48.2 s REU verify floor localises ~10 s of clock- invariant cost to UCI firmware round-trips and network latency. The 64 MHz point was requested but is unobtainable: it exists only on the C64U, which was offline (10.53.21.158 unreachable, different subnet, no ARP entries). Co-Authored-By: Claude Opus 5 (1M context) --- CLAUDE.md | 35 ++++++++++++++++++++++++++++------- 1 file changed, 28 insertions(+), 7 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 746e6b8..1a8e4b3 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -861,13 +861,34 @@ C64U, fits T(f)=D+C/f, residuals <=4.1%): bank 2 $0000-$3FFF residency. At stock 1 MHz the REU profile remains the right default. - HTTPS e2e handshake wall-clock (C64U, local listener): - - profile 48 MHz 64 MHz - v0.3.0 REU 73.0 s 64.7-65.9 s - v0.5.0 onchip 59.9 s 47.5 s (n=3: 47.0/47.6/47.8) - v0.6.0 onchip 51.0 s 39.7 s - v0.6.0 onchip+comb 38.4 s **31.0 s** + HTTPS e2e handshake wall-clock, local listener. **Device is a column, + never a caption** — the REU-profile device delta is 10-13%, so a row + whose device has to be inferred from a heading is not interpretable. + 64 MHz exists only on the C64U (the U64E's CPU Speed enum stops at 48): + + device profile 1 MHz 8 MHz 48 MHz 64 MHz + C64U v0.3.0 REU -- -- 73.0 s 64.7-65.9 s + C64U v0.5.0 onchip -- -- 59.9 s 47.5 s (n=3) + C64U v0.6.0 onchip -- -- 51.0 s 39.7 s + C64U v0.6.0 onchip+comb -- -- 38.4 s **31.0 s** + U64E REU @ 2ceb5b1 1157.7 s 196.5 s 80.8 s n/a (no enum) + + The U64E row is a 2026-08-13 clock sweep at master 2ceb5b1, one clean + `BACKEND=uci` build reused across all three runs so clock is the only + variable, all three PASS with server-side evidence (the listener + decrypted the full GET; no TLS error). Times are handshake + GET + measured C64-side from `run_prg`, not whole-script wall-clock. + + Fitting T(f) = D + C/f to that row gives **D = 58.5 s, C = 1099 MHz*s**, + residuals <= 0.69% across a 48x clock range. Two things follow. The + floor is ~58 s, and the documented REU-profile *verify* floor is + 48.2 s, so roughly **10 s of the e2e is clock-invariant non-verify + cost** — UCI firmware round-trips and network latency, which no amount + of turbo touches. And the returns are visibly diminishing: 1->8 MHz + (8x clock) bought 5.9x, while 8->48 MHz (6x clock) bought only 2.4x. + Extrapolating the fit to 64 MHz predicts 75.6 s, which is why the + REU profile is the wrong choice above ~7 MHz — compare the C64U comb + rows above. Those rows are the 2026-07-20 campaign state. **Current HEAD is faster** — see "Post-#74 e2e numbers" below; the onchip rows in