An user on the libtorrent mailing list had the following problem:
I’m doing some testing for a libtorrent application that will use a small number of peers (often just 1 seed and 1 downloaded) and high bandwidth delay product links (in the hundreds of Mb/s and 100ms+ round trip). I’m unable to get more than 20Mbps with a single peer on a 140ms RTT link (simulated delay with no packet loss). If I take the network simulator delay down to 0, I can get almost a full 1000Mbps on the same system. I’ve tried playing with everything that sounded relevant in session_settings, but nothing seems to make any improvement at all.
Is this the best that can be expected out of uTP on a high latency link? Or is there some combination of parameters that would improve the single peer throughput? Alternatively, is there a way to get libtorrent to make multiple connections between the same 2 peers?
“Did you increase the socket buffer sizes on both ends?”
int recv_socket_buffer_size; int send_socket_buffer_size;
“There’s also buffer sizes at the bittorrent level:”
int send_buffer_low_watermark; int send_buffer_watermark; int send_buffer_watermark_factor;
“And there are buffers at the disk layer:”
int max_queued_disk_bytes; int max_queued_disk_bytes_low_watermark;
If the performance issue happens with uTP but not TCP though, it’s probably
just the first ones that matters.
Also, the uTP implementation needs a system call for each packet sent and
received (i.e. it does not use sendmmsg()/recvmmsg()) which also makes it
more expensive than TCP, but that would primarily cause additional CPU
usage, and only slow-downs once a CPU core is pegged.