V2.01 uTP issues/bugs (random changing of UL limit; high overhead)

[rafi]

I intend to post here some of my test results concerning the overhead in uTP download/seeding. I'll start with an issue of uTP and UL limitter, add add overhead related data later.

1. uTP overhead related issues

Tests setup

- Both seed & peer were local, on the loopback , using two uT instances

- trans_disposition - 10/15 (all connections - using uTP)

- IPs were both IPV4 and IPV6 (torredo - enabled. IPV6 - both local and global IP)

- Speed limiters were used on either the seed of the peer

- Packet sniffer was used to monitor packet sizes.

- uT "transfer cap" pane was used to monitor traffic capacities

- the upper part of screenshots shows the seed, the lower - the peer

A. Overhead is large when seeder has speed limit

- 20-5K UL limit at seed side, peer: unlimited

- Resulted packet size - 665/365B

Overhead: 20-60%

B. Overhead increases when peers' count drops. Wrong capacity measured

setup:

- 136M File transfer

- 300K DL limit at peer side, seed: unlimited

- 3 "peers"/connections established (IPV4/IPV6

- Resulted packet size - 1480B

Peer/seed logs: http://pastebin.com/FbD1RBM1

Wireshark: http://hostfil.es/file/15268/201-loopback-speed-cap-2cycles-OH-issue-pcap.html

found issues :

B.1 - Packet size dropped to 215B when 1 connection drooped. Overhead increased !

B.2 - Wrong capacity measurement - received size - 50M out of 136M .

It feels like the IPV6 peers were not accounted for

2. Randomly changing speed limit

I was shown a speed graph screen-show - where the upload limit - was changing w/o user intervention. Consequently, the Internet connection was constantly chocked . Since it was hard for me to believe - I've tried to recreate this. Unfortunately I succeeded. Below are the conditions & result.

On my connection - 2.5M/250K - it succeeded very easily to chock the connection. Since this is most irregular behavior, and will choke any good seeder's connection, please cancel this ASAP or make an option to disable it (defaulted to disabled). uTP connections' speed should *always* obey the globally set limit. If there is an option that activate this and I've accidentally enabled it - please let me know which one.

Test conditions:

* 2-3 torrents seeding

* 3 upload slots per torrent

* uTP only (transp_disposition = 10)

* XP/SP2

* UL limit - set to 10K / 20K

* No DL limit

* other advanced settings:

- connect speed=3

- ratelimit_tcp_only=true

- max_half_open = 16

- net.utp_delay(s) = 200

Results:

To be continued...

[Atoli]

U: [90K] 10.7 kB/s O: 80.6 kB/s

using 2.0.1 build 18833

[Firon]

That's overhead from your download.

[AppleDragon]

Yes. With TCP we didn't have such overhead from download.

On a well-sourced torrent, I could have downloaded at 1.3MB/s with 5kB/s upload with TCP. With uTP, to download at 1.2MB/s (note the max download speed now unreachable) I have to upload at least at 70kB/s. The upload bandwidth being in fact totally dedicated to answer other peers that yes, I got the chunk I asked.

There's speed issues with the uTP protocol. Too early released to my mind.

[Firon]

You generate far more than 5kB/s upload with TCP when downloading at 1.3MB/s. Even in the best case of a single TCP connection.

[HFerr]

~3% by some tests I did some time ago. 1.3MB/s generates about 40KB/s of upstream data. But 40 is a lot less than 70.

[AppleDragon]

I don't understand, the global upload speed was manually limited to 5kB/s and the whole pool was using 1.8.5.

Keep in mind that when I said a "well-sourced torrent", I meant a high-speed private torrent. On these particular torrents, other peers are not common peers but high-speed 100Mbit/s dedicated server. It's likely that I'm wrong on the explanation of why there's so much overhead with uTP, all I know is that in a pool mainly using uTP, µtorrent can no longer leech on two peers at 650kB/s with 5kB/s upload speed.

In a different way, we could see that as an anti-leech feature, but it's not, all the forced upload speed improvement is used by the download overhead.

[HFerr]

I can be wrong, but I think a upload speed lower than 6KB/s limits the download speed a lot.

Besides that, the upstream data generated by downloads don't count for the upload limit.

[Switeck]

"reducing upload speed reduces download speed"

http://forum.utorrent.com/viewtopic.php?id=73348

[AppleDragon]

Besides that, the upstream data generated by downloads don't count for the upload limit.

So in 1.8.5 limiting the global upload speed didn't have any effect on the overhead from download?

If it's true, that could explain it all. In last version limiting the global upload speed count overheads and effective upload.

[HFerr]

So in 1.8.5 limiting the global upload speed didn't have any effect on the overhead from download?

Yes, at least is what I think.

If it's true, that could explain it all. In last version limiting the global upload speed count overheads and effective upload.

Try disabling bandwidth management. It didn't solved my problem, but can solve yours.