How to increase upload speed

[changmu]

Please provide the following information

libtorrent version (or branch): v1.1.1

platform/architecture: linux x86_64

compiler and compiler version: g++ 4.85

please describe what symptom you see, what you would expect to see instead and
how to reproduce it.

I have a linux server which upload bandwidth is 200MiBit, I wrote a c++ program based on libtorrent v1.1.1, after added several hot torrents to it, its upload speed only around 20MiBits/sec, what can I do to increase the upload speed to around 200MiBits/sec? thank you.

[Falcosc]

I'm very interested in this ticket progress, too.

I did already collect some settings which could be interesting for tuning. #1432

By the way, 20MiBits/sec is a little bit less, even for default settings. Did you check that your client applications could request fast enoght (I mean enoght free download bandwith)? You should host clients on your own network to check the seeding capabilities of your application, then you could get much more predictable test results.

[arvidn]

the problem with that is that the round-trip times to local clients will be a lot shorter than external ones, so you may effectively just circumvent having send buffers configured too small

[arvidn]

to answer your question: https://github.com/arvidn/libtorrent/pull/1717/files#diff-9c8609da69ee3b9cab90f512c2345814R26

[Falcosc]

@changmu
you could try this one (this is based on high performence settings pack)

// 1600mb cache
pack.set_int(libt::settings_pack::cache_size, 102400);
pack.set_bool(libt::settings_pack::use_read_cache, true);
pack.set_int(libt::settings_pack::suggest_mode, libt::settings_pack::suggest_read_cache);
// of 500 ms, and a send rate of 24 MB/s, the upper
// limit should be 12 MB
pack.set_int(libt::settings_pack::send_buffer_watermark, 12 * 1024 * 1024);
// put 1.5 seconds worth of data in the send buffer
// this gives the disk I/O more heads-up on disk
// reads, and can maximize throughput
pack.set_int(libt::settings_pack::send_buffer_watermark_factor, 150);
// always stuff at least 1 MiB down each peer
// pipe, to quickly ramp up send rates
pack.set_int(libt::settings_pack::send_buffer_low_watermark, 1 * 1024 * 1024);

@arvidn some questions about cache_size
Does our own cache implementation work much better then pagecache on linux? Because I don't want to allocate to much of my memory.
And do we have some kind of predictive read cache? Because on a healthy torrent network we don't get a request twice?
I don't know if the current linux kernel does have some kind of predictive read to page cache.

Do you now something about how the clients use the piece suggestions? Because suggest_read_cache would degrade the torrent network health. I would hope that the clients does ignore the suggestion if the suggested pieces are available on 100% of the peers. Does at least libtorrent ignore a suggestion if it is already available by all peers to improve the network health?

How does volatile_read_cache work on a finished file? Does we read the first request into cache and drop it on the second request? Or does volatile_read_cache only make sence during downloading?

[arvidn]

@Falcosc would you mind posting those questions on the mailing list instead? I think that's a slightly better forum. Maybe you can add some details of why the torrent health would be worse by honoring piece suggestions

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.