docs: retract the ~10 s clock-invariant claim + complete the U64E sweep, ip65 re-validation - #88
Merged
Merged
Conversation
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) <noreply@anthropic.com>
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) <noreply@anthropic.com>
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) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #87, which merged with only its first commit. The three commits below were pushed to the same branch afterwards and never reached master.
The first of them is a correction to something #87 shipped, so master currently states it wrongly.
1. Retraction (the urgent part)
#87 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 master says it right now.
The onchip sweep refutes it: a genuinely clock-invariant cost appears in both profiles' floors, and the onchip floor is ~0. Forcing
D=10on the onchip points throws the 8 MHz prediction off by 16%. The correct figure is ~0.6 s — 16 drain polls at ~40 ms, which matches the onchip floor — so the REU profile's floor is almost entirely DMA. The original error was subtracting a verify-only floor from an e2e floor measured under different conditions.2. Sweep completed, crossover measured
The crossover is now measured, not just 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 this hardware can produce. Five-point fits cross at 17.9 MHz against the independently-derived verify-only ~18 MHz.Also records that the onchip
Dmust be read as indistinguishable from zero — the five-point fit returns −0.6 s, a physically impossible floor — rather than quoted as a quantity.Footnote: an inactive REU costs nothing. Byte-identical onchip PRG with
RAM Expansion Unit = Disabled: 44.9 / 262.0 / 2130.9 s at 48/8/1 MHz, deltas under 1.5% and not consistently signed. ZeroNO_SOCKEThits, so a REU-quiet boot did not drop the firstTCP_CONNECTon the U64E — behaviour the C64U notes treat as general. The oneNO_SOCKETseen all day occurred with the REU enabled, which argues for the turbo-switch settle race instead.3. ip65 re-validated at master
VICE ip65 rig, onchip profile, master
2ceb5b1: 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.This one was owed: the ip65 PRG is no longer byte-identical to the #71-era build (
417c708594…vsdb31111031e2…) because #75's span-input parser is real code, and that change had only ever been exercised on UCI. It is also ip65's first end-to-end run since July, so the first to cover #74, #75 and the ten audit PRs.🤖 Generated with Claude Code