upload overhead for large torrents

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Find huge torrent with lots of peers with relatively little seeds (16 
availability when connected to swarm)
2. Download torrent with client_test using only utp (disable tcp)
3. keep an eye on upload speed while monitoring bandwidth used.

What is the expected output? What do you see instead?
Upload speed should be close to the upstream bandwidth usage reported. Instead, 
the client reports something like 23-30kB/s whilst my conky reports 70-78kB/s 
and my latency skyrockets.

libtorrent is maxing out my upload and I don't know where the data is going.

What version of the product are you using? On what operating system?
libtorrent 0.16.1

Please provide any additional information below.

Original issue reported on code.google.com by somethin...@gmail.com on 19 Jun 2012 at 7:29

[GoogleCodeExporter]

One other condition might be relevant.. The data is huge as well, something 
like 20GB+

Original comment by somethin...@gmail.com on 19 Jun 2012 at 7:47

[GoogleCodeExporter]

Maybe this is caused by the same problem that i see sometimes. In that case 
there should be still upload after the torrent was paused or removed. Of course 
there is also download - ul/dl rates are both about 30kbytes/s. This can go on 
for hours.

Unfortunately, this problem goes away if the client is paused for a few seconds 
like then you debug it. (I already tried)
This might be a bug in a different client's utp implementation which libtorrent 
can't handle - or a bug in both implementations.

Original comment by webmas...@massaroddel.de on 21 Jun 2012 at 5:59

[GoogleCodeExporter]

Hmm. I don't see this problem with clients like deluge or qBittorrent though. 
Only with client_test that comes with libtorrent.

Original comment by somethin...@gmail.com on 21 Jun 2012 at 6:51

[GoogleCodeExporter]

I've reviewed the uTP implementation and fixed a few things. Most notably, the 
NAGLE algorithm didn't work quite right. This was primarily a performance 
issue, not necessarily a small-packet-size issue. If you'd like to give it a 
try, it's all checked in to trunk. You can also merge in the changes into 
RC_0_16:

------------------------------------------------------------------------
r7077 | arvidn | 2012-06-25 21:10:53 -0700 (Mon, 25 Jun 2012) | 1 line
fix invalid NAGLE assert
------------------------------------------------------------------------
r7073 | arvidn | 2012-06-25 20:41:04 -0700 (Mon, 25 Jun 2012) | 1 line
fix to new NAGLE implementation
------------------------------------------------------------------------
r7065 | arvidn | 2012-06-24 23:27:37 -0700 (Sun, 24 Jun 2012) | 1 line
fix nagle implementation in uTP

make sure to pick them in the right order.

Original comment by arvid.no...@gmail.com on 26 Jun 2012 at 4:17