Repository navigation
feat(stats): measure the download rate from received bytes, not verified pieces - #35
Merged
Merged
Conversation
…ied pieces The download readout differenced Torrent.Model.downloaded, which moves only when a whole piece completes and verifies. With 1 MiB pieces a 64 KB/s torrent read anywhere from 12 to 157 KB/s, and one slower than a piece per window read 0 while bytes were arriving. Each Peer.Controller now adds every accepted block to a per-torrent counter (Torrent.ReceivedBytes, an atomic ETS update_counter, no messages), and the Model differences that counter over a 20 s sliding window. A live run of two torrents ended with the counter at 100.9% and 102.6% of their sizes, the excess being endgame duplicates. The same number gates Peer.ConnectionManager, whose check accepted only integers while the Model reports a float in bytes per millisecond, so every downloading torrent counted as slow: discovery escalated below 50 peers and the snub path ran above 12 at any speed. It now compares bytes per second against the 32 KiB/s threshold. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
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.
Requested by Daniel Urumov
Before: the download rate was derived from the verified-piece counter, so with 1 MiB pieces a 64 KB/s torrent read anywhere from 12 to 157 KB/s and a torrent slower than one piece per window read 0 while bytes were arriving. The connection manager's "low speed" gate accepted only integers while the rate is a float in bytes/ms, so every downloading torrent counted as slow at any speed: discovery escalated below 50 peers and the snub path ran above 12.
After: the rate is the payload actually received, differenced over a 20 s sliding window, and the gate compares bytes per second against its 32 KiB/s threshold.
How: a new
Torrent.ReceivedBytes(a publicwrite_concurrencyETS table owned by an app-level process) is bumped with:ets.update_counter/4for every accepted block inPeer.Controller.State.count_block/2;Torrent.Model.download_rate/1differences it over its 5 s samples;Torrents.remove/2drops the row;ConnectionManager.low_download_speed?/1accepts any number and converts units. Live: two torrents downloaded on this build with the counter ending at 100.9% and 102.6% of their sizes (endgame duplicates), completed torrents read 0.0, no errors. New tests fail on the old code. All twelve locally reproducible CI gates pass (1880 tests); Trivy, the Codecov upload and the SARIF upload run only in CI.🤖 Generated with Claude Code