Jump to content

ip[utp] kills UL speed on entire client. how to use tcp only


diamonds4u

Recommended Posts

first of all, i am 100% sure that this is what is going on, and i have no idea what the best way of solving this is. there is a lot of info that i can provide but i am confident that it is entirely irrelevant.

UL speed is fine at 375kBps total for an eternity, then suddenly goes down to 0.1~ kBps until peers get disconnected(while DL is entirely unaffected), then suddenly shoots back up to 375kbps and then repeats the same thing when connecting back to the peer over and over in my client. and i know that this only and specifically happens when i see an IP with "[utp]".

note that only UL is affected here. i can even download from someone via UDP but not upload. Ping test.net shows no packet loss. UT client shows the green check mark everything is connect-able. the problem is something is killing speed for my entire client while uploading to a peer with [utp] even on only a single torrent.

the exact same thing thing happens other versions and other clients: -BT6400- -UT2040- and -UT1800-

the same thing happens on several different set-ups as well, different ISP/computer/router/modem

it seems to me that it could be a firewall or my ISP or my router/modem but i don't know the best way to go about solving this. better yet, can i only connect through TCP?

the help documentation and FAQ did not cover this. i'll post some screenshots with my ut settings since it should take long to copy and paste them. please please let me know the solution. it has gotten so bad that i've had to set maximum number of connected peers per torrent to 1 just to make sure i don't connect through [utp]

Link to comment
Share on other sites

  • 3 months later...

with the help of a friend using the exact same internet service, i've managed to resolve the issue. tho hard to explain(or even comprehend), the problem was the dynamic IP address assigned by my ISP on UDP connections. my network would assign an incorrect IP and result in loss of traffic, in lack of better terms.

since the nature of the usage mostly requires that i use a bt_transp_disposition setting at *15 or *31 disabling UDP isn't the best way to go about it, tho i am still learning about this very problem. this has been a very interesting scenario

Link to comment
Share on other sites

  • 2 weeks later...

As I did not want to close all internet connections to do the external speed tests, and wasn't sure how to specify my connection for them, and i did something to some setting so that the uTorrent's own speed test won't work anymore, and i got a little lost amongst the different units and results, also - while just seeding one torrent with few peers, it remained a puzzle why some peers seem to take upload speed from others, no matter what i configured, with limited or unlimited upload rates, so I studied the actual upload speed graphs, and found that my actual total upload rate was about 120 at best, and if i set the max around that it evened out the spikes, but the one peer on uTP was still being squeezed down to an abysmal low rate;

the purple line = TCP upload rate followed the max rate i set, and when i set my max upload rate to 60 instead, this TCP rate stayed at around 60, and so did the non-uTP peer's upload rate, but my actual total upload rate remained at around 120, allowing the uTP peer to use the other 60.

so I assume that the max rate governs the TCP upload, which is then distributed between the non-uTP peers, leaving the remainder for the client using uTP, who otherwise hardly gets a look in. i did jig around with all the other settings i could find and nothing else made a difference.

It seems that if all else is working and you want to give a decent upload rate to uTP clients in a tiny swarm, then you need to set the max rate governing the TCP rate that the others are using, lower than the total upload rate you can achieve, or there's nothing left for the uTP client(s) ???

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...