Jump to content

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


rafi

Recommended Posts

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%

201ohissue130k20k.png

201ohissue120k5k665365.th.png

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

201loopbackpeers.th.png

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 !

201loopbackspeedcap2cyc.png

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

It feels like the IPV6 peers were not accounted for

201loopbackspeedcap.png

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:

utpullimitonoff.th.png

utpullimitonoff1.th.png

To be continued...

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...