qBittorrent overall throughput surpasses BiglyBT & I2PSnark

[provil]

qBittorrent overall throughput surpasses BiglyBT & I2PSnark standalone.

Setup used

i2pd speed = X, share ratio = 100

BiglyBT [anonymous mode only],

[i2p-only mode] qBittorrent + I2Pd,

I2PSnark standalone + I2Pd

quantity = 3

Hops = 1

Variance = 0

5 torrents used and same torrents were used in all torrent clients for testing.

Peers are between 8-15.

All torrent greater than 5 GB in size.

Overall Uploading Throughput.
This is min. & max. speed that torrent client gives irrespective of how many peers connect.

qBittorrent = 600 KB/s to 1.8 MB/s

BiglyBT = 250 KB/s to 900 KB/s

I2PSnark = 100 KB/s to 700 KB/s

I have not tried Java i2p and I2P+ inbuilt i2psnark at the moment, will do so in future. But I am not confidently it will surpass whatever performance I am getting with i2pd setup.

Although, I am really surprised though because qBittorrent still does not have i2p pex or i2p dht, yet outperforms these OGs.

[provil]

qBittorrent to qBittorrent upload is super fast crossing 400-900 KB/s consistently.

qBittorrent to I2PSnark or qBittorrent to BiglyBT upload speed can reach this milestone but lacks consistency. So, fallback is usually in 100-250 KB/s range.

I think on upload side, qBittorrent prefers other qBittorrent peers & uploads to them on a priority.

Does not matter if qBit peer joins late or early in torrent swarm they are always given preference when uploading via qBittorrent.

On download side, qBittorrent, I2PSnark and BiglyBT perform differently.

• Piece optimization for download,i.e, which piece to download next & individual piece size [32kb, 1mb, 8mb, 32mb etc.] handling.
  
  Read/write disk optimization is higher in qBit & BiglyBT than that of snark.

Which helps in them performing better than snark in the long run.


Downloaded a bunch of torrents, same number of peers = same number of seeds, results are as follows


i2psnark - 1 hour 20 minutes,

BiglyBT & qBittorrent under 1 hour.

[provil]

I am getting 2.2 MB/s by uploading in qBittorrent as per above specifications.
As per the aforementioned observations, it is turning to be true.

[zzz]

Interesting test. Did you verify that all three clients have the same bandwidth limit settings?

Snark will query the router for the client bandwidth limit and hold to that. I don't know if Bigly does, and qbittorrent can't via SAM. So snark might be at a disadvantage here.

[provil]

Interesting test. Did you verify that all three clients have the same bandwidth limit settings?

yes sir

[cumlord]

Looks like a pretty good test. While using 3 hops i also was noticing it seems to like other qbit peers and could get very high speeds on one of them. i think you're also probably right about the piece distribution aspect, i've noticed similar things. i2cp works better in java routers than i2pd, could be worth a try, but i think qbit is doing something here