Repository navigation
docs(benchmarks): rented-GPU table re-measured with FUSE_16 - #389
Merged
Merged
Conversation
…90 was host-capped, not slow The first pass (PR #388) used the tuner's default gpuFilterType FUSE_8. With FUSE_8 ~0.78 % of all candidates survive the GPU filter and a rented host's CPU absorbs only ~7-25 M of them per second, which capped every fast card at ~0.5-0.7 G keys/s. Re-measured with FUSE_16 on full-power hosts: RTX 5090 1.59 G -> 1.90 G, RTX 4090 ~0.6 G -> 1.03 G (97 % of its device-timed kernel rate), RTX 3090 565 M -> 612 M (first host was capped at 280 W), RTX 5060 Ti 481 M -> 501 M, V100 310 M -> 377 M, RTX 3070 249 M -> 357 M (first host was capped at 100 W). USD per 10^12 keys recomputed; the RTX 3090 (~0.055) and RTX 5090 (~0.057) are now the cheapest per key. README: new rows and footnotes, methodology for both passes, a same-host FUSE_8 vs FUSE_16 table and the hint to tune with FUSE_16 on fast cards. Raw data in docs/measurements/tuner_vast_fuse16_2026-10-15.csv. TODO.md: the "RTX 4090 not saturated" item is answered; replaced by the tuner gap it uncovered (sweeps under FUSE_8, recommends FUSE_16 with the FUSE_8 winner arm) and the wrong register claim in docs/performance.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MbakdTTChMCjDLiQqfZLvx
bernardladenthin
had a problem deploying
to
maven-central
October 15, 2026 07:25 — with 
GitHub Actions
Failure
GitHub Actions
Failure
bernardladenthin
had a problem deploying
to
maven-central
October 15, 2026 07:25 — with
GitHub Actions
Failure
GitHub Actions
Failure
|
bernardladenthin
added a commit
that referenced
this pull request
Oct 19, 2026
…O.md PR #389 (docs only) went red in three places unrelated to it: SocketResultBroadcasterTest timed out reading a broadcast in the pocl job, the Windows test fork exceeded the 240 s Surefire budget with KeyProducerJavaZmqTest as the only unfinished class, and claude-review fails on every PR without making a model call. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MbakdTTChMCjDLiQqfZLvx
bernardladenthin
pushed a commit
that referenced
this pull request
Oct 19, 2026
Every test started the broadcaster and then probed the port with ConnectionUtils.waitUntilTcpPortOpen. For the plain-TCP broadcaster that probe is a real client: accepted, registered, counted by awaitClientCount. The wait therefore returned before the test's last client was registered, the batch sent next missed it, and its readLine timed out after 15 s. That is the flake of the pocl job on PR #387..#389, reproduced on HEAD in fresh JVMs at 2 of 40 runs, in two different tests of the class. start() binds the server socket before it returns, so the probe is not needed at all; the tests start through a helper that says why. The new onBatchChecked_registrationIsSlow_theOnlyClientStillReceivesTheBatch slows every registration by 300 ms through the existing seam, which makes the race certain: red with the probe (the batch went to the probe), green without, 9/9. Production code is unchanged; the WebSocket tests keep their probe, which completes no handshake and is no client there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VBFFnrhtvXiUeyxjmUc4R2
bernardladenthin
added a commit
that referenced
this pull request
Oct 20, 2026
…O.md PR #389 (docs only) went red in three places unrelated to it: SocketResultBroadcasterTest timed out reading a broadcast in the pocl job, the Windows test fork exceeded the 240 s Surefire budget with KeyProducerJavaZmqTest as the only unfinished class, and claude-review fails on every PR without making a model call. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MbakdTTChMCjDLiQqfZLvx
bernardladenthin
pushed a commit
that referenced
this pull request
Oct 20, 2026
Every test started the broadcaster and then probed the port with ConnectionUtils.waitUntilTcpPortOpen. For the plain-TCP broadcaster that probe is a real client: accepted, registered, counted by awaitClientCount. The wait therefore returned before the test's last client was registered, the batch sent next missed it, and its readLine timed out after 15 s. That is the flake of the pocl job on PR #387..#389, reproduced on HEAD in fresh JVMs at 2 of 40 runs, in two different tests of the class. start() binds the server socket before it returns, so the probe is not needed at all; the tests start through a helper that says why. The new onBatchChecked_registrationIsSlow_theOnlyClientStillReceivesTheBatch slows every registration by 300 ms through the existing seam, which makes the race certain: red with the probe (the batch went to the probe), green without, 9/9. Production code is unchanged; the WebSocket tests keep their probe, which completes no handshake and is no client there. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VBFFnrhtvXiUeyxjmUc4R2
This branch had an error being deployed
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
The rented-GPU table from docs(benchmarks): rented-GPU results from Vast.ai with best settings and USD per 10^12 keys #388 was capped by the host CPU, not by the cards. That pass used the tuner's default
gpuFilterType = FUSE_8. Under FUSE_8 ~0.78 % of all candidates survive the GPU filter, and a rented host absorbs only ~7–25 M of them per second. That capped every fast card at ~0.5–0.7 G keys/s.Re-measured with
FUSE_16on hosts running at the card's default power limit (same kernel and tuner):CMP 170HX and RTX 2070 SUPER keep their FUSE_8 numbers and are marked as such. At their speed FUSE_8 costs little.
RTX 4090 "not saturated" is resolved. With FUSE_16 the card reaches 97 % of its device-timed kernel rate (1.06 G keys/s). Ruled out: provider throttling, filter size, register spills (126–128 registers, no spill), the EC/hash mix, the statistics, and kernel build options.
README: new rows and footnotes, methodology for both passes, a same-host FUSE_8 vs FUSE_16 table (gains of +190 % on the 5090 down to ±0 on slow cards), and a hint to tune with
gpuFilterType: FUSE_16on fast cards.Raw data:
docs/measurements/tuner_vast_fuse16_2026-10-15.csv, 49 arms with agpu_filter_typeandpower_limit_wcolumn. It is indexed indocs/measurements/README.md.TODO.md: the 4090 item is replaced by the tuner gap it uncovered.TuneConfigurationsweeps under FUSE_8 but recommends FUSE_16 together with the FUSE_8 winner arm, which costs ~18 % on a 4090. Options (a)/(b)/(c) are listed there. The item also records thatdocs/performance.md's "≈255 registers with spilling" claim is wrong.The full investigation (findings F0–F14, raw logs, tooling) is on the branch
claude/perf-investigation.Test plan
reuse lintpasses locally (the new CSV is covered by thedocs/measurements/**.csvglob)Related issues / PRs
Refs #388
🤖 Generated with Claude Code
https://claude.ai/code/session_01MbakdTTChMCjDLiQqfZLvx