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?
If you’re facing a similar situation here are some things you could adjust according to Arvid Norberg lead engineer of the libtorrent project.
“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.