Jump to content

uTorrent 1.4 download limiter


krasnal

Recommended Posts

Option to disable:

Feature: Lower download speed if upload is set too low

Many people have stupid admins (internet deliverers) who configure the serwers that lower download speed if upload is too high.

Antidote was 'Global maximum upload rate' set to 1. But now it is not useful becouse this enable limiter :(

PS µTorrent was very good, but I returned to Azureus.

Link to comment
Share on other sites

  • Replies 83
  • Created
  • Last Reply

u know whats wild.....u coulda just used a previous version. I hear ppl saying "I had to switch back to this or that client cuz of a certain feature"...some of us are making this a lil too complicated than it really is. But an option to disable is not a bad idea, or just use a previous version......the latest previous version that I can remember that has it but can be disabled is 1.3.1 beta 189

Link to comment
Share on other sites

I agree with Krasnal here, this is definately not a good "feature" infact it's not a feature at all, it's more like a penalty.

This is one thing that cripples the ability of torrents vs just using good oldschool newsgroups (I hate newsgroups) and things like xdcc bots and stuff like that.

my advise it to remove this "feature".

My reason is this.

People using µTorrent on private tracks are ALREADY forced to upload so this feature isn't even needed.

2ND of all people NOT using private trackers are 80-90% leechers and will just hit and run anyway...

I'm loving µTorrent but this feature is a no no for me...

FOR EXAMPLE:

I share back to the bittorrent community, but I also share things online with people via IRC, FTP etc.

I leave my torrents running 24/7 untill I get to at LEAST 1:1 but my upload is normally spread between bittorent, IRC, FTP etc. So I'm going to be getting penilized for sharing with other clients and people...

I don't think that's right.

And I don't think people that DON'T like nor want this feature should have to use old inferior versions or some other crapped out clients...

Link to comment
Share on other sites

then dont use everything at the same time, the download limiter isnt gonna be taken down however it is gonna be changed to 6* instead of 3* for next version, that should help people with low upload and hurt leechers anyway

and yes, it is a penalty for leechers, that was the point to start with

Link to comment
Share on other sites

so it's capped at 3x your upload speed for download?

My upload is about 85 and download is like 650, even at FULL upload speed I couldn't achieve my full download speed.

and a full upload speed would just throttle my downloads anyway which would make it pointless.

LEECHERS get thier accounts deleted from private trackers anyway so I really don't see the point.

so even at a 6x multiplier I can't achieve full download speed...

Link to comment
Share on other sites

uTorrent works fine with or without a built in speed limiter based on upload cap. It works fine because it closely adheres to the BT protocol despite this arbitrary limit imposed on the user. Nevertheless, arbitrary limits that do not reflect the BT protocol or the spirit of the BT protocol are a bad thing.

When you start fiddling with arbitrary limits not based on the BT protocol, uTorrent stops working fine. BitComet is proof of that.

Instead of pushing either for more download speed without consideration for others as BitComet does or pushing for less leech appeal as uTorrent currently does, it would be better for all to push away from either of those two extremes and push more towards a general adhesion to the BT protocol through better behavior detection of other clients that do not conform to the BT protocol.

I read AllWeasel's posts on the Rufus BT client and its choker logic, the LeoXV choker. I think the LeoXV choker is a better solution than any other arbitrary limits imposed on the user. The more intelligent uTorrent becomes without imposing arbitrary limits, the better it will work for everybody, including other clients that connect to uTorrent.

In fact, I propose we write a choker logic in text in this forum to help uTorrent development.

ML

Link to comment
Share on other sites

uTorrent does not detect the speed of your connection if you set it at unlimited upload and/or download speed. What happens in this case is uTorrent tries to send and/or recieve as much data as it can but since your connection cannot handle both max upload and download, one or both of them will suffer.

For example, if you upload at max speed, you will not be able to send TCP traffic for the download you're getting so it will be slower. Same thing happens when you download at max speed, you will not be able to receive TCP traffic for your upload so it will be slower. One affects the other and vice versa. That's the reason it's essential that you limit your upload within uTorrent to about 70% of your actual upload capacity to allow TCP traffic to pass through.

When you set a limit to your upload, uTorrent will throttle its speed to try to maintain it to that limit.

If you use NetLimiter to limit your speed and set it to unlimited in uTorrent, uTorrent will still try to send and recieve as much data as it can but since you limit your speed outside of uTorrent, the 3x (6x in later versions possibly) download cap will not come into effect (I'm not sure since I didn't try that and I will not try it either).

You could do that if you wanted to fool uTorrent so that you could leech more and upload less but eventually uTorrent will be made more intelligent to detect those that do that and will not act favorably towards those peers. What I mean by that is that it will probably not be made to detect an outside speed limiter such as NetLimiter but instead it will be made intelligent enough to detect other peers that just want to leech.

There is one problem that you will see if you use NetLimiter to try to fool uTorrent. NetLimiter will limit all types of traffic that passes through your connection, that includes both data and TCP traffic. uTorrent's limiter does not count TCP traffic. For example, limiting uTorrent to 50kB/s and limiting NetLimiter to 50kB/s is not the same thing. uTorrent will limit data traffic to 50kB/s but the total amount of traffic that passes through your connection will include 50kB/s by uTorrent and the TCP traffic that uTorrent uses on top of that. Netlimiter will limit all traffic at 50kB/s so if you need 10kB/s TCP upload traffic because of your download, you will only have 40kB/s upload available. Now imagine doing the same thing but at 1kB/s upload limit in NetLimiter.

ML

Link to comment
Share on other sites

Another problem you will see if you use NetLimiter to try to fool µTorrent is µTorrent probably doesn't know to limit its upload slots based on real upload speeds. So if you set upload slots to 4 per torrent and you have 4 torrents and used NetLimiter to limit µTorrent's upload bandwidth to 10 KB/sec...then µTorrent's uploads would be running at less than 0.6 KB/sec each -- possibly even lower than 0.3 KB/sec each. Other BitTorrent clients might start snubbing your client as it doesn't deliver what it offers -- after all µTorrent doesn't realize what its real upload limits are, and stupidly thinks it can do more! After that, download speeds might drop off slowly or drastically -- depending on whether the torrent is well-seeded or not.

Link to comment
Share on other sites

We (80 persons) have the DSL 4Mbit/512kBit.

We have internet restriction (set on server by our admin): Lower download speed if upload is too high.

For expample: if my upload is higher than 3-5kB/sec server will turn on download transfer limit to 2-3kB/sec.

Therefore to fast torrent download I have to set 'Global maximum upload rate' to 1KB/sec.

With uTorrent 1.4 it is not possibility, becouse we have feature: Lower download speed if upload is set too low.

But if I set 'Global maximum upload rate' to 1KB/sec for uTorrent 1.4 process with NetLimiter all work good :) I have high torrent download transfers (100-300kB/sec) :)

Link to comment
Share on other sites

the download limiter "anti leeching" feature would be more just if it was based on percentage of upload speed instead of on absolute upload speed.

For instance, instead of limitting the downloads of a user who caps his upload to 1-5kBps,

Limit the downloads of users who cap their upload below 40% of their max upload speed.

This way, the mechanism won't be as biased against slow connections, as it is today.

Link to comment
Share on other sites

Sorry if I wasn't clear enough. this is what I mean:

I think that a person with a max upload of 100KBps who caps to 50KBps is as much a leech as a person with 10KBps upload who caps to 5KBps, if not more. (The second person leaves less upload for other needs).

If the limiter was to be based on percentage, it would be the most fair mechanism.

Link to comment
Share on other sites

But if I set 'Global maximum upload rate' to 1KB/sec for uTorrent 1.4 process with NetLimiter all work good :) I have high torrent download transfers (100-300kB/sec) :)

Not good, unless you upload some later on torrents that need more seeds. While you're seeding, if your admin doesn't limit your upload based on other people's activity...then you need to limit your upload speed to no more than 10 KB/sec.

When you set NetLimiter to 1 KB/sec, you're giving less than 1 KB/sec upload spread between EVERYONE in your torrents. I would at least hope you only download 1 torrent at a time, limit upload slots to 1, and limit µTorrent's max upload bandwidth to 6 KB/sec (even though you're using NetLimiter to reduce that further). And you might as well turn off DHT too...at least for torrents with >20 seeds+peers.

It's ok if you don't upload 1:1 on well-seeded torrents, considering your connection...but you really should try to upload at least 50% on every torrent you get.

Otherwise, you're just an unabashed leech that is ruining BitTorrent for everyone else.

Link to comment
Share on other sites

There is where the problem lies.

Krasnal wrote that he can still leech by fooling uTorrent's built in throttle with NetLimiter. uTorrent can be fooled so the built in throttle is effectively useless. Nothing we say will prevent him or anybody else from taking advantage of the inherent failures of uTorrent or any other BT client.

If instead uTorrent was made more intelligent towards other peers, there would be no need for self policing since any leech that connects to a uTorrent peer will be at a disadvantage and eventually this leech will see its download rate diminish until the leech realises what's happening and changes his methods or client.

Or, uTorrent will be updated to detect any external app that limits uTorrent's speeds and will act accordingly. Eventually this app will be updated as well and the whole circle will start again. A patch over another patch and so on.

Or, uTorrent will be made more intelligent in detecting its own behavior towards other peers and will resume throttling itself. uTorrent will be made less attractive to all as a result. Who sets the values with which uTorrent throttles itself? One does not fit all.

I can make a case for limiting upload to less than the value that triggers uTorrent's throttle other than because I want to be allowed to leech all I want. I don't simply want to leech, I also want to seed to at least a 1-to-1 ratio. I want to get the file as quickly as my connection allows and I want to seed at the highest speed my connection allows. The faster I get the file, the faster I can seed it in return, the faster other peers can get the file as well once I become a seed.

I will not be able to do that if uTorrent throttles my connection in any way yet I will still be able to do that using another client that does not throttle my connection. I can still do it because there are few clients (and few peers that use those clients) that are intelligent enough not to be fooled. Leeches can still do it as well for the same reasons.

Eliminate uTorrent's own restrictions since they can be circumvented using external applications. Instead, implement some sort of choker that will help everybody. An intelligent choker will not be very attractive for a leech, be it a user or a peer.

When a patch does nothing except annoy the user which in itself becomes a problem that must be addressed, remove it.

ML

Link to comment
Share on other sites

But if I set 'Global maximum upload rate' to 1KB/sec for uTorrent 1.4 process with NetLimiter all work good :) I have high torrent download transfers (100-300kB/sec) :)

And THAT'S the point of some sort of download cap. You shouldn't be using BT, you're probably killing every BT file you download, or do you expect me to believe that you upload a 100-300kb/s downloaded file up to a ratio of 1 or EVEN 0.5 with an upload of 1kb/s?

Maybe the cap should be removed altogether as it is. I mean, I'm always getting a download speed equal to 4xUpl, with my current or previous connection. So, raising the cap to 6x practically nullifies it. We should request some sort of ration/global stats check every week/2 weeks/whatever and capping download THEN until ratio reaches an acceptable level. But even than can be bypassed, if people delete μTorrent settings before the ratio check. Maybe write something in the registry or whatever, I don't know.

Maybe the cap should be more intelligent like -> check average global upload speed every 15-30 minutes, and IF the average download/upload speed ratio is TOO high (like Down>5xUpl), cap download speed accordingly THEN, and continue checking until the ratio is ok.

And I agree, implementing some sort of choker to monitor peers' and μTorrent's own behaviour would be good.

Link to comment
Share on other sites

Limiting uTorrent's own behavior is a bad thing unless the user has control over it. Who sets the limits otherwise? One size does not fit all.

Three situations.

1. A client that acts any way it wants within a swarm that allows such behavior. This is the current situation with regards to the way BitComet acts towards the swarm.

2. A client that acts in a limited fashion within a swarm that allows any behavior. This is also the current situation with regards to the way uTorrent acts towards itself and towards the swarm.

3. A client that acts any way it wants plus is also configurable to prevent leech behavior in other peers that connect to this client. This is also the current situation but with regards to a limited number of clients (Rufus and G3Torrent and perhaps others I don't know about) and with an even more limited number of peers that use these clients.

Situation 1 dominates the BT universe. Situation 2 only patches one client for the good of the swarm but not for the good of this particular client because it is still vulnerable to situation 1 and because nobody wants a limited client. Situation 3 solves all problems, those of the client and those of the swarm.

Which situation do you prefer?

Check this thread http://forum.utorrent.com/viewtopic.php?id=4746 , I just thought of another idea that could be implemented instead of a bandwidth throttle.

ML

Link to comment
Share on other sites

Form whatever opinions you wish of me but I don't particularly care.

I'm on an NTL Cable connection in the UK here and for those that don't know, the UK has very pants uploads. I have a 128 KB download which translates to 10 Kb/s a second. Unfortunatly, my download gets saturated at that rate, so I have to cap at 5 Kb/s to keep it optimum. Now, I don't think it's the makers of uTorrents business whether I should have my download capped as a result of this. I'm a member of several private trackers, maintain good ratios and have never been banned from one. How do I do this? By leaving my computer uploading and not constantly downloading. When I'm seeding one of my own torrents, I uncap my upload so people can get the full 10/12 Kb/s from me.

So please, all I ask is that this is removed, you've managed to sway me away from other clients with the whole low resources concept and minimalistic approach. Don't lose your userbase with a silly little addition like this.

Regards,

Andre

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...