Torrent peer discovery, trackers and performance (#352)

Date: 2026-11-06. Question it answers: how the app's torrents find peers and how fast they download today, measured, and which changes are worth trying next.

This is research, not a decision. It changes no engine behaviour. Each proposed change is its own issue, to be measured before and after.

Code read at: 92d626b (main), with libtorrent-rasterbar 2.0.15. Measured with: the torrent helper built from that commit in release mode.

How facts are marked:

• Code: read in this repository at that commit.

• libtorrent: read in libtorrent 2.0.15's source (src/settings_pack.cpp at tag v2.0.15).

• Measured: from the runs in part D.

• Assumed: not checked; a reason to measure.

Short answer

• Small torrents are fast and steady. Debian's 0.8 GB image finished in 88 to 95 s in all six runs, at 8.3 to 8.8 MiB/s.

• Large ones are not. Ubuntu's 2.9 GB image took 323 and 346 s in two runs of six, and 764 to 1321 s in the other four, at both times of day.

• The slow runs wait for peers at the start (#386): one peer for about 15 minutes, then the whole swarm at once. Why is #387's question.

• Peers are found quickly. The first peer came within 0.5 to 5 s, and the metadata within 0.5 s, in all twelve runs.

• Most of the engine runs on libtorrent's defaults. The app sets discovery, ports, limits and the proxy; choking, piece picking, uTP and the disk are libtorrent's choices.

• One privacy bug was found and fixed: the Extra trackers setting reached private torrents (#377).

A. What the app sets today

From crates/velocity-torrent/src/engine.rs (session_config) and crates/velocity-lt/cpp/shim.cpp (code):

Left to libtorrent 2.0.15 (libtorrent), with their defaults:

After a restart: a torrent's own trackers come back with its resume data. The user's extra trackers are added again from the settings when the torrent is restored (code).

B. Public tracker lists

Some download managers add a long list of public trackers to every torrent, to find more peers. The options for the PO:

For every option:

• Privacy: each extra tracker learns the user's address and the torrent's info hash. PRIVACY.md would have to say so.

• Private torrents never get them. That rule is now enforced and tested (#377).

• Dead trackers cost an announce each and are retried; libtorrent backs off after failures (libtorrent's tracker back-off, assumed, not measured here).

• Legal: public trackers are used for all kinds of content. Whether the project should point users at any is for the PO and Singlbase.

Not measured: whether a public list finds more peers for the well-seeded torrents in part D. They already reached the 55-peer limit, so it likely wouldn't help there (assumed).

C. Performance and reliability

Each item is a hypothesis with a way to test it.

D. Measurement

The method

crates/velocity-torrent/examples/torrent_baseline.rs, run by hand, never in CI:

cargo build --release -p velocity-torrent --bin velocity-torrent --example torrent_baseline
target/release/examples/torrent_baseline target/release/velocity-torrent <.torrent file> <work folder> <runs>

• Each run starts fresh: a new helper with the app's default settings, in a new folder, so it remembers no peers or DHT nodes.

• Only the port differs: 6891, so it can't clash with a running app.

• What it reports: times to the metadata, the first peer and the first byte, and to completion; the mean speed from the first byte; the peak speed as the best 5 seconds, so one burst isn't called a speed; and the most peers and seeds seen.

• It cleans up: each run's download is deleted.

• Its sums are tested: cargo test --no-default-features -p velocity-torrent --example torrent_baseline.

The torrents

The results, Windows 11, the PO's PC and connection

Set 1, 2026-11-06 from 20:01 (measured):

Set 2, 2026-11-06 from 23:11 (measured):

Spread over both sets (measured): Debian 88 to 95 s, median 92 s. Ubuntu 323 to 1321 s, median 976 s; 2 of 6 runs near the direct-download time, 4 slow.

What the numbers say

• Repeatable for Debian: all six runs within 7 s, at both times of day.

• Not for Ubuntu: the fast runs match Debian's speed, and the slow ones reached the same peak. It happened at both times of day, so it isn't only the hour. While watching run 1, its download was at 2.79 of 2.93 GB and gaining about 0.6 MB/s, so at least part of the time went at the end. That is one observation, not a measurement.

• Against direct downloads: single HTTP downloads of the same Ubuntu file took 286 s in V1 and 294 to 319 s in the app on this connection (2026-10-30, one run each). Ubuntu run 3, at 323 s, is close to that. The two slow runs are not.

Where the slow runs lose their time (#386, 2026-11-07)

The tool now saves every half-second sample (<work>/run-<n>.tsv), the slowest 30 seconds of each run, and the trackers' states (run-<n>-trackers.tsv). Five more Ubuntu runs, built from main at 8c7280e (measured):

What the samples show (measured):

• The slow runs lose their time at the start, not the end. Runs 1 and 2 had one peer, not a seed, for 900 s, and gained about 2 MB a minute: 33.8 and 40.3 MiB done at 900.6 s.

• Then the swarm arrives at once. By 910.6 s they had 16 to 20 peers, by 930 s over 30, and the rest of the file took about 4 minutes at full speed.

• Run 3 waited too, for less: 2 to 5 peers for its first 6 minutes, then 48 by 420 s.

• The fast runs had 27 to 32 peers within 30 s.

• The trackers, in the fast runs: torrent.ubuntu.com answered over IPv4 within 1.5 s, reporting about 1,120 seeds. The IPv6 tracker always failed ("unreachable"): this connection has no working IPv6.

• Not yet captured: the trackers' answers in a slow run. The tracker log was added after runs 1 to 3.

The lead (assumed, not proven): 900 s is libtorrent's dht_announce_interval (part A). A run whose first announce gives it almost no peers waits for the next DHT round. Why the tracker gave so few in those runs is what #387 has to find, with the tracker log now in place.

E. The plan

In the order recommended, each its own issue. Which release each goes in is the PO's choice.

Not proposed: changing the peer limit, uTP or the disk settings. Nothing measured points there yet.