Arvid Norberg

I just read through (most) of this thread. Here are some observations: 1. the libtorrent python bindings never call back into python from within libtorrent. Early versions attempted to do...

do you have any (verbose) libtorrent logs from those test runs where the download did not start for a long time, or did not reach the max throughput for a...

do these tests pin down whether TCP or uTP is used? One aspect I can imagine might affect this, is if the startup of the swarm is somewhat random, the...

I haven't gotten around to setting up an ubuntu VM to run this in. But I have some comments anyway: 1. If ``netem`` (the ``tc`` command) works on the loopback...

the stall in the last run looks like they got stuck checking files or something. and if the first connection attempt fails, there may be a delay before trying again....

great, 1.1.6 is good. A more direct approach to understanding a throughput bottleneck would be to post session stats counters regularly and log them to a file. That's basically what...

each session object you construct is independent. There's no invisible state they share (other than the usual, filesystem, network interfaces etc.) They will all open listen sockets independently, two will...

remove_torrent() is an async. Call. It’s not obvious though how add_torrent() could jump ahead of it

Oh, maybe it’s the other peer trying to connect before it’s been added. Sync. With add_torrent_alert.

I have a suspicion that the first result is CPU bound. UDP is significantly less efficient than TCP at high rates, since (traditionally [1]) every single packet needs a system...