From 7b0652fe7c7b0dc27844dd20616a99532fb32a18 Mon Sep 17 00:00:00 2001 From: JC-000 <3798556+JC-000@users.noreply.github.com> Date: Thu, 13 Aug 2026 10:49:12 -0500 Subject: [PATCH 1/3] docs: add U64E onchip sweep; retract the "~10 s clock-invariant" claim Adds the onchip-profile clock sweep on the U64E (1 MHz 2120.7 s, 8 MHz 264.5 s, 48 MHz 45.5 s) alongside the REU row, and fits both: REU D = 58.5 s C = 1099 MHz*s residuals <= 0.69% onchip D = 0.5 s C = 2120 MHz*s residuals <= 1.92% Measured e2e crossover 17.6 MHz vs the independently-derived verify-only ~18 MHz. RETRACTION. The previous revision of this section claimed the REU floor minus the documented 48.2 s verify floor localised "~10 s of clock-invariant non-verify cost". The onchip sweep refutes it: a clock-invariant cost would appear in the onchip floor too, and that floor is ~0.5 s. Forcing D=10 on the onchip points throws the 8 MHz prediction off by 16%. The real fixed network cost is ~0.6 s (16 drain polls at ~40 ms, which matches the onchip floor), and the REU floor is almost entirely DMA. The error was subtracting a verify-only floor from an e2e floor measured under different conditions. Also flags that the onchip D is poorly conditioned (at 48 MHz the C/f term is ~99% of the total) and should be read as "under ~2 s". Cross-validation retained: the two-point onchip fit predicted 1 MHz at 2104 s before that run existed; it measured 2120.7 s, +0.8% over a 48x extrapolation. Co-Authored-By: Claude Opus 5 (1M context) --- CLAUDE.md | 44 ++++++++++++++++++++++++++++++++++---------- 1 file changed, 34 insertions(+), 10 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index 1a8e4b3..eaf94a1 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -872,6 +872,7 @@ C64U, fits T(f)=D+C/f, residuals <=4.1%): 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) + U64E onchip @ 2ceb5b1 2120.7 s 264.5 s 45.5 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 @@ -879,16 +880,39 @@ C64U, fits T(f)=D+C/f, residuals <=4.1%): 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. + Fitting T(f) = D + C/f to those two rows: + + U64E REU D = 58.5 s C = 1099 MHz*s residuals <= 0.69% + U64E onchip D = 0.5 s C = 2120 MHz*s residuals <= 1.92% + + **The two profiles differ in floor, not just slope**, and that is the + whole story of the crossover. REU carries a ~58 s floor that no clock + touches, because `fp_mul`'s row fetches are anchored to the ~1 MHz + bus; onchip has essentially none, paying instead ~1.9x the + clock-scaling work. Solving the two fits gives a measured e2e + crossover at **17.6 MHz**, against the independently-derived + verify-only figure of ~18 MHz. + + Two cautions on reading these fits. The onchip D is **poorly + conditioned** — at 48 MHz the C/f term is ~99% of the total, so D is + fitted from what little is left; treat it as "under ~2 s", not as + 0.5 s. And an earlier revision of this section claimed the REU floor + minus the 48.2 s verify floor localised "~10 s of clock-invariant + non-verify cost". **That was wrong**: a genuinely clock-invariant + cost would appear in the onchip floor too, and it does not (forcing + D=10 on the onchip points throws the 8 MHz prediction off by 16%). + The fixed network cost is instead ~0.6 s — 16 drain polls at ~40 ms, + matching the onchip floor — and the REU floor is almost entirely DMA. + + Returns diminish steeply on the REU profile: 1->8 MHz (8x clock) + bought 5.9x, 8->48 MHz (6x clock) bought only 2.4x. Extrapolating it + to 64 MHz predicts 75.6 s, which is the quantitative case for the REU + profile being wrong above the crossover — compare the C64U comb rows. + + A cross-validation worth keeping: the onchip fit built from only the + 8 and 48 MHz points predicted 1 MHz at 2104 s before that run + happened; the measurement came in at 2120.7 s, +0.8% over a 48x + extrapolation. Those rows are the 2026-07-20 campaign state. **Current HEAD is faster** — see "Post-#74 e2e numbers" below; the onchip rows in From a5610e551497e6a7ad57fe19fe89faea82d834cf Mon Sep 17 00:00:00 2001 From: JC-000 <3798556+JC-000@users.noreply.github.com> Date: Thu, 13 Aug 2026 20:25:58 -0500 Subject: [PATCH 2/3] docs: crossover bracketed to [16,20] MHz + inactive-REU footnote MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Adds 16/20 MHz columns to the U64E rows, completing the sweep: REU 1157.7 / 196.5 / 124.0 / 108.9 / 80.8 s onchip 2120.7 / 264.5 / 131.8 / 103.9 / 45.5 s (1/8/16/20/48 MHz) The crossover is now measured rather than only fitted: REU wins at 16 MHz by 5.9%, onchip wins at 20 MHz by 4.6%, so the sign flips inside [16, 20]. There is no 18 in the CPU Speed enum, so that is the finest bracket the hardware allows. Five-point fits cross at 17.9 MHz (17.6 from three points) against ~18 MHz from verify-only data. Footnote: an inactive REU costs nothing. The same byte-identical onchip PRG with RAM Expansion Unit = Disabled gives 44.9 / 262.0 / 2130.9 s at 48/8/1 MHz — deltas under 1.5% and not consistently signed. Zero NO_SOCKET hits, so a REU-quiet boot did not drop the first TCP_CONNECT on the U64E, contrary to what the C64U notes imply is general. Also the first confirmation of the shipped "no REU required" onchip claim on UCI hardware rather than in VICE. The onchip 16 MHz figure is the median of two retries; the first attempt died on UCI_ERR_NO_SOCKET ($88) with the REU *enabled*, which argues against REU-quiet boot as the cause on this device. Records that the onchip D must be read as indistinguishable from zero (the five-point fit returns -0.6 s, physically impossible) rather than quoted as a floor. Co-Authored-By: Claude Opus 5 (1M context) --- CLAUDE.md | 76 ++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 53 insertions(+), 23 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index eaf94a1..9482a94 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -866,32 +866,62 @@ C64U, fits T(f)=D+C/f, residuals <=4.1%): 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) - U64E onchip @ 2ceb5b1 2120.7 s 264.5 s 45.5 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 those two rows: - - U64E REU D = 58.5 s C = 1099 MHz*s residuals <= 0.69% - U64E onchip D = 0.5 s C = 2120 MHz*s residuals <= 1.92% + device profile 1 MHz 8 MHz 16 MHz 20 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 124.0 s 108.9 s 80.8 s n/a (no enum) + U64E onchip @ 2ceb5b1 2120.7 s 264.5 s 131.8 s 103.9 s 45.5 s n/a (no enum) + + The U64E rows are a 2026-08-13 sweep at master 2ceb5b1. One clean + build per profile, reused across that profile's clocks, so clock is + the only variable within a row. Every run PASSes 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 (which runs ~35-55% higher: boot, table init + and turbo setup). + + The onchip 16 MHz entry is the median of two retries (132.4 / 131.2). + Its first attempt died on `net_last_error = $88 UCI_ERR_NO_SOCKET` — + the TCP_CONNECT bridge glitch, not a result. Note that failure + occurred with the REU *enabled*, which is evidence against the + REU-quiet-boot explanation for this device and in favour of the + turbo-switch settle race. + + **Footnote — an inactive REU costs nothing.** The onchip rows above + ran with the device's REU enabled but unused. Re-running that + byte-identical PRG with `RAM Expansion Unit = Disabled`: 48 MHz + 44.9 s (-1.32%), 8 MHz 262.0 s (-0.95%), 1 MHz 2130.9 s (+0.48%). + Sub-1.5% and not consistently signed, i.e. noise, not an effect. + All three PASS with zero `NO_SOCKET` hits, so a REU-quiet boot did + **not** drop the first TCP_CONNECT on the U64E — behaviour the C64U + notes record as general. This is also the first confirmation of the + shipped "no REU required" onchip claim on UCI hardware rather than + in VICE. + + Fitting T(f) = D + C/f across all five clocks: + + U64E REU D = 56.4 s C = 1101 MHz*s max|resid| 2.35% + U64E onchip D = -0.6 s C = 2121 MHz*s max|resid| 4.09% **The two profiles differ in floor, not just slope**, and that is the - whole story of the crossover. REU carries a ~58 s floor that no clock + whole story of the crossover. REU carries a ~56 s floor that no clock touches, because `fp_mul`'s row fetches are anchored to the ~1 MHz - bus; onchip has essentially none, paying instead ~1.9x the - clock-scaling work. Solving the two fits gives a measured e2e - crossover at **17.6 MHz**, against the independently-derived - verify-only figure of ~18 MHz. + bus; onchip has none, paying instead ~1.9x the clock-scaling work. + The fits cross at **17.9 MHz** (17.6 from the three-point version), + against the independently-derived verify-only figure of ~18 MHz. + + That crossover is **measured, not just fitted**: REU wins at 16 MHz + by 5.9% and onchip wins at 20 MHz by 4.6%, so the sign flips inside + [16, 20]. There is no 18 in the CPU Speed enum, so that interval is + the finest bracket this hardware can produce. + + Read the onchip D as *indistinguishable from zero*, never as a + quantity: the five-point fit returns -0.6 s, a physically impossible + floor. At 48 MHz the C/f term is ~99% of the total, so D is fitted + from rounding. This is the same ill-conditioning the turbo campaign + hit with 2-point fits. Two cautions on reading these fits. The onchip D is **poorly conditioned** — at 48 MHz the C/f term is ~99% of the total, so D is From dfce6c5c18c8ca3b578f452c00bffe7913244669 Mon Sep 17 00:00:00 2001 From: JC-000 <3798556+JC-000@users.noreply.github.com> Date: Fri, 14 Aug 2026 08:14:40 -0500 Subject: [PATCH 3/3] docs: ip65 e2e re-validated at master (first run since July) VICE ip65 rig, onchip profile (REU-less stock-C64 config), master 2ceb5b1: PASS, http_status=200, resp_len=22, body match, 1,876.0 s accelerated against the 1,813.9 s reference (+3.4%). Phase shape unchanged. The reason this run was owed: the ip65 PRG is no longer byte-identical to the #71-era build (417c708594... vs db31111031e2...) because #75's span-input parser is real code. That change had only ever been exercised on UCI. This is also ip65's first e2e since July, so it is the first to cover #74, #75 and the ten audit PRs. Co-Authored-By: Claude Opus 5 (1M context) --- CLAUDE.md | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/CLAUDE.md b/CLAUDE.md index 9482a94..96d9410 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1006,6 +1006,7 @@ feth/pcap rig (see "VICE ip65 rig" under Smoke tests). These are the ip65 + onchip, no REU honest 1 MHz **2,159.7 s (36.0 min)** ip65 + onchip, no REU ~1.2x accelerated 1,813.9 s ip65 + REU profile ~1.2x accelerated 988.9 s + ip65 + onchip @ 2ceb5b1 ~1.2x accelerated 1,876.0 s (2026-08-13) Honest-1 MHz phase breakdown (seconds after 'G'): TCP CONNECTED 3.0 | CH 329.2 | SH 700.7 | PROC 718.9 | @@ -1016,7 +1017,18 @@ feth/pcap rig (see "VICE ip65 rig" under Smoke tests). These are the holds at 1 MHz, three orders of magnitude from where it was fit. - X25519 scalarmults measured 326 s / ~356 s vs ~324 s analytical. - ip65's drain budget is **unchanged by #74** (the ip65 PRG is - byte-identical across it), so these numbers stand at HEAD. + byte-identical across it), so those numbers stand at HEAD. + - **Re-validated at master 2ceb5b1 on 2026-08-13**: PASS, + `http_status=200`, `resp_len=22`, body match, 1,876.0 s + accelerated (+3.4% vs the 1,813.9 s reference). Phase shape + unchanged: TCP 3.0 | CH 276.0 | SH 585.4 | PROC 600.6 | + FIN 1,823.0 | REQUEST SENT 1,838.2 | CLOSED 1,841.2. This matters + beyond the number — the ip65 PRG is **no longer** byte-identical + to the #71-era build (`417c708594...` vs `db31111031e2...`) + because #75's span-input parser is real code, and until this run + that change had only ever been exercised on the UCI backend. It + was also ip65's first end-to-end run since July, so it is the + first to cover #74, #75 and the ten audit PRs. - VICE 3.10 SDL2 has no usable runtime warp: its `Speed` resource caps at ~1.2x and `WarpMode` is gone, so "accelerated" runs are only ~1.2x. Divide accelerated figures by ~1.2 for honest 1 MHz.