Download speed issue

[JeViCo]

For some reason i'm getting around 6 MiB/s when running example (ubuntu distro magnet link)
Self-hosted solutions (running 1 torrent seed via transmission-remote & 1 torrent tracker) shows even lower numbers: it's getting capped to 0.5 MiB/s

Using qBitTorrent client instead shows around 11 MiB/s for both. It was an attempt of using librqbit 5.6.1 with tauri.
Here's tauri info in case it helps:

[✔] Environment
- OS: Windows 10.0.22621 X64
✔ WebView2: 119.0.2151.58
✔ MSVC: Visual Studio Community 2022
✔ rustc: 1.77.2 (25ef9e3d8 2024-04-09)
✔ cargo: 1.77.2 (e52e36006 2024-03-26)
✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
✔ Rust toolchain: stable-x86_64-pc-windows-msvc (default)
- node: 18.18.0
- pnpm: 8.14.0
- yarn: 1.22.21
- npm: 10.5.0

[-] Packages
- tauri [RUST]: 1.6.1
- tauri-build [RUST]: 1.5.1
- wry [RUST]: 0.24.7
- tao [RUST]: 0.16.8
- @tauri-apps/api [NPM]: 1.5.3
- @tauri-apps/cli [NPM]: 1.5.11

[ikatson]

A few clarifying questions:

1. Did it work better before?
2. What's the commit/version you are using?
3. Can you repro with "rqbit" and "rqbit-desktop" binaries or only with your librqbit usage? Not sure how is tauri related.
4. "Self-hosted solutions (running 1 torrent seed via transmission-remote & 1 torrent tracker) shows even lower numbers: it's getting capped to 0.5 MiB/s". Do you mean that with localhost server you get even lower speeds?

[JeViCo]

Okay, so i'm using 5.6.1 version of librqbit. i've also tested on both 4.0 and 5.0 and download speed stays in same ranges so it's probably not related to recent changes.

Can confirm same thing happend on pre-built executable (5.6.1) and rqbit-desktop (5.6.1)

As for the self-hosted torrent tracker & seed, i'm using two separate remote ubuntu 22.04 machines. Tracker is running on the first machine in quoorex/bittorrent-tracker container and seed is running in linuxserver/transmission container on the second one. Both use network_mode: host

[JeViCo]

I have a suspicion that 0.5 MiB/s speed happens due to multiple file ~300 being downloaded instead of one

[ikatson]

How can I repro this?

Here's how I test localhost to localhost torrents:

cargo run --release -- --disable-dht download -o /tmp/test/ /tmp/test.torrent --disable-trackers --initial-peers 127.0.0.1:27311 --overwrite

where /tmp/test.torrent is a torrent generated by another client on localhost, and 27311 is that client's TCP listen port.
I'm getting hundreds of megabytes per second.

[ikatson]

Tested on a Windows VM, got ~100mb/s in the VM with the above method.

[JeViCo]

Here's torrent file of Ubuntu i'm also using https://drive.google.com/file/d/1iVLPJH2c_RMUuIIj_6dE_Yt_mihe5jC3

I've also noticed that qBittorrent shows 30 seeds and number doesn't change over time while rqbit has around 20 (if "live" equals seed count) and it's constantly drops and raises. For example, it shows "live: 12" on start, a minute later it shows "live: 20" which drops to 6 the next minute. Not really sure what's happening. The higher the value "live" has, the higher the download speed i get

[ikatson]

I was getting ok speeds on this torrent, But the number of live peer changing too much was concerning - it should be more stable. Looked in the logs and found a relatively recent bug.

After the bugfix here's what I see on macos for this torrent

[ikatson]

There are a few things at play here:

1. The most concerning thing from your report is low speeds on local network. I surely can't repro this, so please give it some more testing. Can try local qBittorrent and use a command line like I used above.
2. Also please try v5.6.2 (being released right now)
3. As for qBittorrent seeing more peers, there might be 2 explanations for this, both can apply at the same time. The first one is the bug above, the second is that rqbit doesn't support μTP protocol which can work over NAT and thus see more peers. In practice it was never a problem.

[JeViCo]

Just switched to bugfix branch and peer count change is fixed for sure. It also looks legit after you mentioned μTP (totally forgot about it)

Here's the second torrent file i'm struggling with (1 seed 1 tracker):
https://drive.google.com/file/d/1WdV0L3u_2c0HjDQC0SjkThF7QDws8dqJ

It should have the exact same download speed as previous one but it 10 times worse and capped (unless there're some options/flags which applies in librqbit)

[ikatson]

I can't connect to the lone peer so can't repro. But if that's you seeding from some other client, please try another one and see if it helps.
Maybe it's your server client that is throttling for some reason, not sure. rqbit itself doesn't cap speed in any way

Btw found another bug while was debugging this - apparently trackers aren't even polled if DHT is enabled. That is also appeared after a fairly recent refactor.

Can you check #127? Maybe that was the culprit, as the only other client that rqbit was discovering was itself over DHT.

[ikatson]

Also to validate it's not the tracker polling code, can you please check with "--initial-peers" passed in explicitly like I provided in the example above

[JeViCo]

I had some issues with peer ports on my side. Could you try one more time?

[ikatson]

It's downloading, but slowly, uploading faster than downloading

↓0.18 MiB/s, ↑0.86 MiB/s

If there is any throttling, it's done by the other side.

I also tried qBittorrent to see if that is faster, but it didn't download anything at all somehow

[JeViCo]

0.86 - that's probably was me. But still 0.86 is higher than download speed we get. I'll try changing machine

[JeViCo]

So i moved my stuff to a completely different provider. I replaced tracker image to lednerb/opentracker-docker in process. Changing tracker increased download speed somehow for my colleague however in qBit only. rqbit don't want to raise speed higher than 0.6. Here's the most recent torrent file
https://drive.google.com/file/d/1qNo6plwweveBgL0KAOX6VBW9P6OFarug

Don't mind one offline tracker, it's previous one

[ikatson]

It's 0.50Mb/s download speed for me. It's actually very stable at that speed. Note, the tracker itself doesn't matter, cause all it's needed for is to discover the peer (ip:port combination). It's the peer that is sending data, not the tracker.

So replacing the tracker wouldn't have done anything. It shows this peer: kind: Transmission, version: ['4', '0', '5', '0']

Maybe on that peer you have a bandwidth limit set? Try changing it to another client e.g. qBittorrent.

[JeViCo]

Yeah, i've noticed it's too much stable as well. I'll try changing client instead

[JeViCo]

Good news. Swapping seed's docker image with qbittorrent increased speed significantly. Either changes not applying or i did something with my setup idk. For now, download speed is pretty decent and still much better than 0.5 mbps

I'll double check some things before giving the final response

[JeViCo]

Okay, so problem is partially solved, at least for the ubuntu torrent i posted earlier. Download speed is accurate here.
As for the self-hosted solution, i'm getting only 50% of qbittorrent speed (rqbit ~5 mbps, qbittorrent ~10 mbps). I'm deleting a single large file to check the download speed. I have no clue what could be the cause of such bottleneck and how to debug it

[ikatson]

Is there a chance qbittorrent sees more peers? As mentioned before, there's nothing limiting in that code path, and it easily hits hundreds of mb/s if peers can send so fast

[JeViCo]

Turned out there were multiple issues which affect download speed. One of them is ping-related and it's being solved here #130. Another one is related to low write speed of the disc which slowed down a whole process. Hope it'll be fixed soon