uTorrent 1.4 download limiter

[hofshi]

Andre: I totally agree with you.

[Switeck]

In the µTorrent 1.4 released thread (11th page), I came up with a PARTIAL solution to the problem.

Not my idea of 30 KB/sec download cap if upload less than 6 KB/sec...that's just a partial workaround for the 6x cap.

The one about µTorrent limiting upload slots per torrent to ONE anytime the max allowed upload speed PER PERSON drops below 1 KB/sec. It may need to do that even at higher speeds.

This isn't about punishment, there is an implicit and explicit expectation in the BitTorrent protocol to NOT open too many upload slots or it chokes TCP acks. In short, NOT doing so is breaking the rules.

Fewer people will actually get downloads from these (choked?) uploaders but the fewer upload slots would be going considerably faster and more chunks could be uploaded to help out the torrent. On well-seeded torrents such as OpenOffice, seeds+peers would upload to you for lack of anyone else to upload to. But on poorly-seeded torrents, download speeds would fall like a brick when someone sets their upload speeds too low. They'd be uploading to only 1 other person -- and only that 1 person and the seeds would be likely to be uploading much to them in return. They'd be getting the occassional optimistic unchokes from other peers -- but not constant leeching from them as they would return little to nothing in return. That sounds fair either way.

We set the upload slot max, but µTorrent and the BitTorrent protocol should decide the minimum.

Lastly, this would partially solve the problem of slow uploaders. It would also solve the problem of faster uploaders who open way too many torrents + upload slots for their connection.

[zone]

as everyone here, I'd like this "feature" to be removed. It's just plain annoying and pointless. And I certainly wouldn't like it in the future to be raised at 10kb/s (*cough* emule *cough*)

I hardly ever set my upload speed below 8~10 kb/s (my connection is theorically 128 kb/s down, 16kb/s up), but at times I want to see webpages or stream something to my friends without the horrible lag. I will seed overtime the damn torrent as close to 1:1 as possible, so what's the deal? it's not my fault i dont live in happy land with happy upload speeds..

edit: btw.. the one who suggested using an older version, that's just plain stupid. where's the rss support and all the goodies to come?

[Firon]

zone: get cFosSpeed? :/

[Firon]

other clients don't actually limit the upload slots, you do know that right? if a user sets 100 upload slots on a 10kb/s connection, other clients will USE 100 slots.

µTorrent on the other hand, actually does limit them, your upload cap / 3

[Switeck]

other clients don't actually limit the upload slots, you do know that right? if a user sets 100 upload slots on a 10kb/s connection, other clients will USE 100 slots.

µTorrent on the other hand, actually does limit them, your upload cap / 3

They are breaking compliance with the BitTorrent protocol by doing so.

µTorrent limits upload slots per torrent to upload cap /3?

But what if someone foolishly runs lots of torrents?

If each torrent gets upload slots = upload cap /3, then it's the same problem, it just won't happen as quickly.

µTorrent could also queue torrents instead of starting them, in spite of user settings, if upload speeds are insufficient to allow even 1 KB/sec PER torrent. Note: Nearly inactive torrents would not need to be counted against this limit. By nearly inactive, I mean torrents which there are either few peers per seed or the peers all have the same parts and are waiting on the seed/s to give them something else.

[Firon]

It used to do limit active torrents, but the function was removed

[hofshi]

Firon, could you let us know if the download limiter will be removed/changed in the next release?

thanks...

[Kazuaki Shimazaki]

Doubt it, hofshi. As I said in the 1.4 thread, you will get 18-30KB/s with the new version even with a upload at 3-5KB/s. Even with a 3x and 15KB/s at 5KB/s upload, it is hardly atrocious. Tell me, how is it unfair to you to get the similar speeds to the ones we get a lot of the time despite uploading at about ten times your lousy rate? In fact, I'd call this a serious injustice to us. It is like paying money ten fast faster and getting nothing in return.

At any level of generosity, a guy with a fast upload simply will wind up giving more back. You may think you are generous spending 1165 extra hours trying to repay a 4GB download at 5KB/s (I'd assume you had a share ratio of 0.166 at the time of your completion). The simple fact is however, that I can repay 10 times that much at the same time, thus I will be, as far as the torrent is concerned, ten times as generous as you, no matter how much effort you think you are putting out.

In general, if you manage to repay once, you are not considered a leech even if you didn't give your all - results are what counts in this cold world, not effort. Besides, what do you think is the relative probability of someone willing to spend 1165 seeding hours vs one willing to spend 116.5 seeding hours?

Let me ask you, hofshi. I remember you saying you gladly leave files on your hard disk to seed until they reach 1:1. That's nice, but tell me - how big a percentage of the hard disk are those seeding torrents of yours taking? If you suddenly see this torrent you want right now, are you likely to have enough HDD space to put it on? Because it is simply very convenient to leave things on the hard disk and seed them where disk space is still abundant.

I hardly ever set my upload speed below 8~10 kb/s (my connection is theorically 128 kb/s down, 16kb/s up), but at times I want to see webpages or stream something to my friends without the horrible lag.

In zone, we have another example of the seeding = charity mentality. Again, uploading is a second place to his wants. He can't even say that his VOIP or (probably illegally acquired) Battlefield 2 software's connection would stutter - he's doing it just to save a few seconds. Since it is hardly critical, I simply cannot understand why he compromise by setting it at 6KB/s. With about 10KB/s upload theoretical upload free, and probably 4-8KB/s practical free, he should be able to get webpages in a delayed but hardly unreasonable time.

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.

I don't know what special circumstances you have, Krasnal. I do know that whatever your reason, this kind of setting is seriously harmful to the torrent. Maybe you can consider being forced to use Azureus as a kind of alternate payment - you get the download, but you pay for it by not being able to use your computer. In a way, I think that poetic justice.

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.

It may be that, at some time in the future, compact advanced AI to determine leechers may be possible. From what I understand of this kind of logic-based choker, however, little of this would please hofshi and his low-upload bandwidth buddies in the long run either. A client has very limited ability to see what's going on with everyone else (fog-of-swarm), and it would find it rather difficult to find out if hofshi is a leech or is just limited by his connection. Most likely, if this is implemented everywhere, hofshi would notice a very slow download rate because he's a slow uploader. Instead of complaining about uTorrent's hard cap, they would now complain about this new choker conspiring against them.

On a less serious aside, let's say we can somehow create a choker that would note that hofshi deliberately choked off his connection so he can communicate on VOIP or play Battlefield 2 (no fog-of-swarm). Never mind this being a rather serious breach of privacy, but should the choker punish him for this?

-------

As for any idea that letting us disable this kind of control, I am sorry but I can only go ROFTLMAO. Either we have such self-regulation or we save space by deleting it. Do you think anybody would leave this kind of thing on if they can easily switch it off? It doesn't matter if they are never to activate the limit - this is a matter of principle.

[hofshi]

Kazuaki Shimazaki: I appreciate the time that you put into your reply, but you fail to address the issues that were raised.

unfortunately, my posts from yesterday got deleted. I have no idea why anyone would delete them, but I'll try to summarize the main points again:

1. IMO someone who has a fast connection who is capping his upload to 30% of his max, is still a leech. Even if his max is 100kBps. The current limiter doesn't address this issue. That's why I say that the current limiter is biased against slow upload connections.

2. You miss-quoted me as saying that I alway keep my torrents until a ratio of 1 is achieved. This is plainly wrong. I always keep them until they die naturally, which makes for ratios of double to tripple digits. Ask yourself, Do you do the same?

3. As a result, I give precedence to seeding a torrent over HD space.

4. And please try to be open minded about this and understand the following point:

All that really matters is ratios, not upload speed !

to demostrate this, consider the following:

a. when using Bittorrent you almost always get a download speed that is higher than your upload speed to the swarm.

b. The total download speed in the swarm equals the total upload speed in the swarm.

c. From a. and b. the conclusion is that when you join a swarm you reduce the average download speed in the swarm!

d. You joining the swarm is still a good thing because you help the uploader/seeders to distribute the content.

You still aren't convinced that I'm right? consider this:

There is a swarm with two nodes - the uploader/seeder, and another peer with infinite upload speed who is 50% complete. Now you join the swarm.

you will get to 50% in no time, but your time to completion is dependent of the upload speed of the seeder. The infinite upload speed of the downloader won't help you to get your time to completion to zero.

The result of all that is that the commulative upload speed of seeders is what really counts when you want a short time to completion. Hence, what really counts is people staying to seed.

That is to say, what really counts is ratios and not upload speeds.

Granted, if you have a high upload it's easier for you to achieve high ratios, but it's still the ratios that count.

I may have a slow upload connection, but I have excellent ratios. Do you?

Edit: to the mods/devs this is why I claim that the limiter should be based on ratios and not on absolute upload speeds. Another alternative is to detect the max upload speed of the user and making sure that the user doesn't cap his upload below a certain percent of his max upload. I'm not sure if that's possible to implement though.

[Kazuaki Shimazaki]

Kazuaki Shimazaki: I appreciate the time that you put into your reply, but you fail to address the issues that were raised.

unfortunately, my posts from yesterday got deleted. I have no idea why anyone would delete them, but I'll try to summarize the main points again:

1. IMO someone who has a fast connection who is capping his upload to 30% of his max, is still a leech. Even if his max is 100kBps. The current limiter doesn't address this issue. That's why I say that the current limiter is biased against slow upload connections.

His 30% still produces more results than your 100%. Why is he the leech? Is someone a thief if he is a millionaire and pays the same price as you for a piece of candy? In my book, as long as he at least repays the part in reasonable time, he ain't a leech and he benefitted the crowd.

2. You miss-quoted me as saying that I alway keep my torrents until a ratio of 1 is achieved. This is plainly wrong. I always keep them until they die naturally, which makes for ratios of double to tripple digits. Ask yourself, Do you do the same?

OK, I might have confused Megasaint with the ordinary saints. Nevertheless, this is meant as something of a universal answer. It is enough of a struggle to seed a large torrent (1165 hours is 48.5 days) at the speeds you use that seeding it to 20-30x is hardly possible before the torrent dies. At most by the time you do so, you are probably only helping out a few stragglers, not the bulk of the crowd - to which you basically owed a debt. I just don't see you seeding for more than two years.

3. As a result, I give precedence to seeding a torrent over HD space.

Really. Either your HDD is really big or you only occasionally need a torrent. If you see my claim sheet (P.10 in the deleted thread), I've admitted I'm hardly a saint. I've got only 6-8GB of space free by the time all my other programs are on, and thus the deck is cleared regularly. Even so, I easily maintain close to a 1:1 - not saintly, but average, and all without special effort or sacrifice. Which means not counting deliberate leechers who lock their downloads down to <6kB/s, a lot of people with my kind of connection or better will not be a leech, while a lot of people with your kind of connection will be a leech.

a. when using Bittorrent you almost always get a download speed that is higher than your upload speed to the swarm.

1) This is theoretically impossible (Conservation of Total Transfer Mass) as you yourself pointed out. If everyone "almost always" gets a download speed that is higher than their upload, the torrent collapses.

2) The current BitTorrent implementation is actually somewhat socialist, favoring the slowpokes more than their upload warrants. In my experience, the benefit to your download from uploading more goes in one of those marginal utility curves. With 6kB/s up on a torrent, a typical ratio when finished is about 0.2. With standard speed (54KB/s out of a 80 theoretical and 64 practical up connection in my case), a typical ratio is 0.8-1 or even more. As I type this, I'm uploading at my standard speed and am being rewarded by a 14.6KB/s download. This actually happens to me a lot and that AntiLeech guy apparently is a similar victim.

2b) Maybe with the ultra-fast crowd the curves inverse again, but I doubt it and I won't know about that from my practical experience.

3) Item A in my experience holds true with slow uploading speeds which explains your experience. This is the reason why leech downloading is an attractive option - download does not increase in proportion to upload, so why not hook to three torrents each at a slow download rate? But here you are seeing the BitTorrent "economic strata" that pays the price (medium speed and maybe the high speeders as well, though they won't notice it as much). Which is why it should be discouraged (I've said Items 2 and 3 in the deleted thread too, on P.10).

c. From a. and b. the conclusion is that when you join a swarm you reduce the average download speed in the swarm!

C follows from A, so this is logical I guess, but the premise in A is wrong and really quite impossible, so it falls down.

d. You joining the swarm is still a good thing because you help the uploader/seeders to distribute the content.

True.

You still aren't convinced that I'm right? consider this:

There is a swarm with two nodes - the uploader/seeder, and another peer with infinite upload speed who is 50% complete. Now you join the swarm.

you will get to 50% in no time, but your time to completion is dependent of the upload speed of the seeder. The infinite upload speed of the downloader won't help you to get your time to completion to zero.

False. It won't get it down to zero, but the peer's contribution is still immensely important. In an idealized implementation, what happens when you join the swarm is that the seed will give both of you pieces. Say there are 1000 blocks total. The seed may give Infinite Peer Piece 501-750 and you Piece 751-1000. Infinite peer would then, in this scenario, instant transfer anything it receives. Effectively, you get the full bandwidth of the seeder

Now assume if Infinite peer decides he wants to play Battlefield 2 and limits his upload to 6kB/s. It is easy to see how your download would be greatly delayed.

In fact, in a situation where a full copy is available between the peers, the peers may find it more efficient to just trade the needed pieces among themselves without reference to hofshi the Peer with his 6KB upload.

Granted, if you have a high upload it's easier for you to achieve high ratios.

And that's why it is that way. Statistically, most people will not wait 1165 hours (six weeks) to refill their ratios after downloading 4GB. Sure, there might be a few saints, but rules and regulations are not made on the basis of saints. If you are such a saint, you can afford to wait a little for a longer download. Remember, as it is, the new rules mean you are getting the same type of speeds as we often get while uploading at 10x the rate.

About the ratio based system: Now, here's where the guys with little disk space will begin to protest - we won't mind getting better ratios, but we have to clear the decks a lot.

[hofshi]

well, I think that in some of your points you actually proved mine.

From the general tone in your post I can deduce that you're only in it for the argument and are not keeping an open mind about the issue, so I'll stop at that, and not try to correct some of your false statements. If I'm wrong in my conclusion than I'm truly sorry, but in any case I think you can see where I'm going from my previous post. try to read it again, I don't think you gave it much attention or even a fair chance at you first read.

I'll give you the final word.

[Kazuaki Shimazaki]

In a sense, I am doing it mostly for the argument, since it is quite obvious that any such chokers would not affect me - I maintain good enough ratios and upload speeds that either way I don't think I'd be in the penalized category.

However, if you feel dissatisfied with my answer, please do speak up. I think I can see where you come from since your fight with AntiLeech on the Deleted Thread, but perhaps my experiences just do not match yours (particularly your claim that DL is "almost always" more than UL - I only wish this is true for me!)

I like to think that I'm a fairly typical BitTorrent player, and everything I've seen in Forums so far imply I am indeed average. I have a medium speed connection. I download both big and small torrents, strong and weak... My choice of client is more based on efficiency than ethics. I seed when possible but clear my deck when I need to recover the space.

[Martin Levac]

This is my experience with different torrent sources.

My upload is greater than my download. This is a result of not enough upload from all other peers/seeds to feed me at my maximum capacity. The result for the swarm is an addition to total swarm bandwidth.

My upload is equal to my download. This is also a result of not enough upload from all the other peers/seeds to feed me at maximum capacity. The result for the swarm is no change in total swarm bandwidth.

My upload is lower than my download. Depending on whether I reach maximum capacity, this is a result of enough upload from all the peers/seeds to feed me faster than my upload can feed the swarm back or enough to saturate my connection. The result for the swarm is a reduction of bandwidth in certain parts of the swarm (those other fast peers that were fed from the bandwidth that I now use), no change in bandwidth (those peers that I can feed back using my upload capacity), an increase in total swarm bandwidth (slower peers that can be fed back from either myself or the other faster peers that feed off me).

The more desirable situation of the three is the third one since it allows fast peers to become seeds in a shorter amount of time. The upload bandwidth that these fast peers were eating is now redistributed to the swarm thereby increasing the total upload bandwidth available at that point. That all depends on each individual seed's seeding state with regards to their upload bandwidth.

It is also the more desirable situation since the file can be used now yet still be seeded afterwards for who knows how long.

About the choker and slow peers versus plain leeches.

A mechanism that determines who gets to trade with me does not consider if the peer has a slow connection or is just plain leeching. It only considers if that peer will trade with me at a minimum speed that I set and/or at a minimum quantity of completed blocks per period of time. In either case, the peer that has a slow connection and the peer that is leeching, the result is that they will be sent to other slow peers of similar bandwidth and will still be fed, just not by me. They may still be fed at some point by me or any other intelligent peer but not as fast as those who trade with me on a regular basis.

The slow peers that want to trade, will trade because they want to trade. The leeches that don't want to trade, won't trade because they don't want to trade. It's that simple and it's precisely for that reason alone that a choker does not need to consider if the peer is a leech or a slow peer. All it needs to consider is if the peer is willing to and actually trades at or above the minimum speed/ratio/whatever that this client has set.

Integrating some kind of self policing is also a good thing but not in the fashion currently implemented. Instead, set a limit to the total number of connections to peers (not seeds since they don't need the upload from me) for the client if the total amount of available upload bandwidth per peer is lower than x. X being whatever the user sets. This will allow the user to determine his own settings based on his preference. Obviously, combined with a choker that determines who gets to trade will result in peers of similar bandwidth capacity connecting to each other and eventually trade at a faster pace. All this while keeping the leeches at bay or if you prefer, keeping them out of the swarm for all intents and purposes.

An example. I set upload limit to 50kB/s and BW per peer to 1kB/s, I get 50 connections to peers not counting connections to seeds. Combined with optimistic unchoke mechanism that activates one connection once in a while, I could be feeding 50 peers at 1kB/s. Not all at the same time since there would only be a limited number of upload slots, let's say 10. Combined with an intelligent choker, I could be fed by those 50 peers at 1kB/s per peer. Add the seeds I'm connected to and there's no telling how high my download will go. I know one thing for sure, it will remain at least as high as my upload for a very long time.

A similar function already exists although it is an arbitrary fixed limit set by Ludde. It is also easily fooled using an external application. One size does not fit all and in that case it doesn't fit as intended either.

In a swarm of intelligent peers, a peer with high upload capacity and even higher download capacity that purposely limits his upload speed to something ridiculously low will get sent down the pipe to connect to other slow peers and will see his download speed dwindle until he realises that his method isn't working as it should.

Let's see how well it would work if I set this limit to 0.1kB/s per peer. Any other intelligent peer who set his choker limit to 1kB/s will refuse to trade with me. Fair enough. Any unintelligent peer that can be fooled is fooled and will trade with me. Not so fair for the swarm but I'm a leech so I don't care about the swarm. Any intelligent peer that do not trade with me will still get to trade with intelligent peers that set limits close to each other as well as unintelligent peers.

We'd have a choker to get good connections and a self choker to play nice with the swarm. In an intelligent client, there's no need for fixed limits since this client will be used by intelligent users. For abusive users who use an intelligent client in an abusive manner, please refer to the previous paragraph. I remind us all that the connections limit and the bandwidth limit are imposed on the user in uTorrent. I remind us all that the bad behavior of other known clients is imposed on all users, even themselves.

Nevermind all that for a second. If at any point Ludde chooses to include some sort of choker, it will have to be configurable by the user. As it was with the network and torrent settings within uTorrent, not all users know what they're doing and not all users want to use the default settings so there'd have to be a choker wizard for those of us not so inclined to fiddle and experiment.

The restrictions on connections and bandwidth only limit the user of uTorrent while while uTorrent remains vulnerable to abusive clients that connect to uTorrent clients. The situation is only fixed on one side and even then it is not fixed completely because of the potential for abuse from other peers. Nobody wants to be limited as well as to remain vulnerable to the problem the limits are trying to fix.

ML

[Kazuaki Shimazaki]

Martin Levac

1st Section: I get a lot of the third kind of situation, and the way BitTorrent is implemented now, my experience tells me DL>UL (1st scenario) is more likely with slow uploaders. Sometimes, however, it may not be such a good idea in practice (from the POV of Swarm Health) to let a fast fish finish too fast - too many people would pack bags as soon as they're done, depriving the torrent of their fat pipe.

2nd section: Speaking personally, I won't mind such a choker. Remember my ethics are only average and anything that increases my control over who I connect to gets a plus in my book. Now that I've confirmed that the choker would indeed not discriminate b/w real slowpokes and leechers, I can already assure you this feature would be a long time in coming (likely never) due to Ludde's personal policy. I can also reaffirm my previous point - this new choker, widely implemented, won't help slowpokes like hofshi and thus won't stop them screaming.

This problem will worsen if Ludde chooses your implementation, which involves manual control of the parameters. It approaches a "Kick and Ban" switch in some ways, which is another feature Ludde would never allow. There will also be a horde of people asking how to best set these settings on the board - just setting upload slots and connections is tough for many people. Yet if we choose automatic parameters (presets or algorithms), it will reduce the potential for abuse, but Ludde will instead be inundated with people with fringe circumstances demanding changes in the algorithm.

[hofshi]

I don't think I ever screamed, did I

unlike you, Kazuaki Shimazaki , I try to be polite and civilized, and not provoke unnecessarily.

[HaiRy]

I'm sorry but discussing all the technicalities is great and all but you have to think practically about this. I've used a 2 Mbit connection before elsewhere, it had a 384 upload rate on it and I used it to good extent. It boosted my downloads a lot and helped seeding. But right now I'm only on a 128 Kb upload, I don't have any choices BUT to cap my upload at a low rate. IMO, if the principal isn't built into the BT protocol then the makers of clients don't really have the right to do this. Futhermore, no matter how hard we try, a computer will never have personal opinion or feeling, it cannot judge individual circumstance. The makers of this program may believe that I'm a cancer that must be killed but maybe if they saw individual circumstances they might see differently.

[Martin Levac]

Hit and runs cannot be prevented by any means, it does nothing to try. uTorrent is not the only BT client, if a leech can't leech using uTorrent, he'll use another. uTorrent, even if it's not attractive to leeches, is still vulnerable to leeches because they can use other clients.

Slow peers are not discriminated against by a peer with an intelligent choker. Since they are willing to trade and actually trade, all that's left is how fast they trade. Leeches, on the other hand, do not want to trade and will effectively be taken out of the swarm leaving an effective healthy swarm of intelligent peers, whether slow or fast. A choker does not ban peers, it simply chokes them for a while and eventually disconnects consistently choked peers to look for new, willing peers. As AllWeasel wrote in one of his posts about the subject, his experience shows that the LeoXV choker works best with small values (0.5kB/s to 3.5kB/s).

I remind you all that the function that disconnects inactive peers is not a function of the choker, it's already a part of the BT protocol and can be configured within uTorrent. The choker works on top of that function.

This choker idea is only an extension of the BT protocol. It allows a healthy swarm to survive longer because it allows data to be distributed throughout a swarm of willing peers. It allows peers to reach higher speeds because it matches peers based on each peer's individual settings. It allows all peers of all speeds to get data for the same reason. It prevents leech behavior because it prefers willing peers.

ML

[ICleolion]

I expect this thread to become the largest. Cause this argument is gonna carry on forever.

[hofshi]

maybe if one of the mods/devs will post his opinion, it won't have to... :wink:

[Firon]

hofshi: beta 405 changed the cap to 6*

[ICleolion]

The only developer of µtorrent has already given his opinion by coding in this feature in the first place. He doesn't need to state it again.

[hofshi]

Firon I am well aware of that. As I stated in one of my posts, I am hardly ever affected by this limiter, but I am annoyed that it is built into the client. I also think that the criteria for the limiting is the wrong one, and should be based on ratio.

[Martin Levac]

Hofshi, I oppose any limits imposed on the user except those that are required for the client to work properly (those that are specified by the BT protocol, for example). Any limits imposed on uTorrent's users will cause those users to switch to clients that do not have those limits. A leech that wants to leech will use another client. A user that does not want to leech will probably use uTorrent because those limits will probably not affect him but uTorrent remains vulnerable to leech behavior from other clients.

ML

[chaosblade]

I disgaree. Leechers will use whatever clients that helps them leech, True.

I dont think anybody that sees this cap should switch unless they are leechers or have a completely bizzare and unreasonable situation requiring them to upload so slowly. In either case its harmful to the torrent anyway.

If a programs is designed to teach good ettiqute, i see no problem with that.