User Configurable Choker (as in the LeoXV choker)

Greetings,

This is a feeble attempt at helping Ludde develop uTorrent. I ask that any that can participate contribute here with his/her knowledge and wisdom.

I want more control over the way uTorrent works because I want to be able to fine tune it to my own preference. I want uTorrent to be more effective and more efficient. I recently learned that it was possible to control the client's behavior with regards to other clients' behavior so that this client could prefer to connect to nice clients instead of being at the mercy of ruthless clients like BitComet. I learned this by reading posts by AllWeasel about the LeoXV choker. The LeoXV choker is a choker logic that is configurable by the user that allows the client to work more efficiently by determining more easily and more quickly which other peers either worked nicely themselves or were just faster.

I don't know much about the LeoXv choker but I can deduct that it collects and maintains information about each peer that the client connects to and analyses this information to determine if the client maintains a connection to these peers. It wades through the swarm looking for nice and fast peers with which to trade data. Those that don't play nice get lost, those that don't want to trade get lost. Only those that play nice and want to trade will get preferential treatment from the client that uses the LeoXV choker. Only those two factors are good enough to get good speed throughout but it can be infered that average speed is also a factor in the decision to keep or break the connection. That's the general idea of the LeoXV choker.

Proposed choker logic, I begin below.

Logic.

Rules with related actions:

1. Prefer peers that have something to trade.

Yes is a keeper, no is a goner. Short timer.

2. Prefer peers that want to trade.

Yes is a keeper, no is a goner. Medium timer.

3. Prefer peers that actually trade.

Yes is a keeper, no is a goner. Long timer if trade happened in the past, otherwise go through rules.

4. Prefer peers that begin trading quickly.

Dependent on prior rules. Short timer.

5. Prefer peers that keep trading.

Timer only when trade is interrupted.

6. Prefer peers that trade at high speed.

Comparison must be done with user settings and/or with other peers performance.

7. Prefer peers that trade at high average speed.

Comparison must be done with user settings and/or with other peers performance.

8. Prefer peers that play nice.

You'll have to help me here.

Tha't a start, waiting for replies. The logic above is applied both to determine if the connection is kept but choked and if the connection is terminated to look for better connections. The potentials that determine either must be devised.

ML

Hm... I guess it's not that big of a problem opening this thread, since the previous one was locked... but here's the old one for you to know what's been discussed already...

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

All I read in that thread was "I want it, now put it in". I do more than ask, I propose to help.

ML

I think the ultimate problem her is with "I want to be able to fine tune it to my own preference".

I dont think BT SHOULD be able to be customized. The good thing about it is that the protocol is unifed, and all clients should follow exactly that. If some clients or some people with a certain client started changing the behavior around to match their needs, We're losing the uniformity here. True, that might help in regards of screwing around bad clients and bad peers, But thats still something i see as bad in regards that all peers in the swarm should be considered equal.

Chaosblade, you disagree. Thank you for your input.

I just thought of this but I read it earlier from AllWeasel. I think it would be better if the client prefered peers that sent at least 1 complete block (16kB) in a period of time (to be determined). It dawned on me that a client could be made to cheat by sending only partial blocks.

Another choker rule configurable by the user. Reduce the total number of connections if total available upload bandwidth per peer is below x. Much like the choker would disconnect or choke peers that do not send me enough data in a period of time, this will allow the client to play nice with the swarm on its own.

Don't count seeds connected for this rule above. In fact, don't count seeds connected for any rule that controls the number of connections. The more seeds are connected to me, the better. Unless a seed just takes up a connection without sending me anything then there must be a method to sift through inactive seeds to be connected only to active ones.

There must be an extension to the rule above when seeding to make seeding more efficient.

Treat seeds differently than peers when downloading from them. Apply similar choker rules to seeds but instead of choking them as it would with peers, it would refuse to download from seeds who don't send enough data to be worth it. This will force those seeds to either reduce the number of upload slots manually or by ricochet since this client will not accept any data from those seeds. Whatever data this seed gives will go to fewer peers.

Treating seeds differently brings some difficulties with the number of connections to maintain. There must be a fudge factor built in to the number of connections allowed to allow seeds to connect since uTorrent only determines if the peer is a seed or not once the peer has connected.

So, trade with willing peers. Choke those who don't trade. Choke seeds who give little to no data. Choke itself by way of limiting the number of connections to allow sufficient upload bandwidth to each peer. Allow increasing (or decreasing) the number of upload slots to maintain a consistent upload limit set by the user while maintaining reasonable upload speed to each peer being uploaded to. Allow inactive peers disconnect to take its course. Add "waited" state in inactive disconnect function but perhaps double its timer.

Allow the user to set all threshold parameters so he can fine tune uTorrent for his connection and preference.

ML

Another idea that might make the choker less intrusive or more effective overall.

Have the choker run after the normal inactive interval runs out on peers that haven't sent enough data to meet the quota but still sent keepalive during that period for whatever reason. Instead of choking them prematurely, keep those peers in the optimistic unchoke cycle for the interval. Instead of disconnecting those keepalive peers after the initial intrval, choke them for the next interval and give them that interval to prove themselves. If at the end of this extension the peer still hasn't sent enough data, then disconnect it same as if it had been inactive and put it at the end of the round robin queue.

By default the interval is 5 minutes so it would give those keepalive peers 10 minutes to prove themselves. Count only the data being sent during the second interval for quota purposes if no data or not enough was sent during the first interval.

ML

sorry, double post

After doing some cursory reading, I like the LeoXV choker. It seems to be a smarter version of the standard chocking algorithm, and may prove effective at increasing the health of the swarm. I don't know if I want tons of user configurability though since, afterall, what good is implementing a better choker if nobody's definitions of a "bad" client to choke match?

JigPu

One size does not fit all. Not everybody has the same connection or preference. I'm trying the Rufus client right now and I must say I'm missing many features from uTorrent. I don't see a marked improvement in speeds over uTorrent but I do see a consistency in speeds except perhaps when seeding.

A side note. One feature of the Rufus client I'd like to see in uTorrent is the max connections per torrent. There's two numbers, one for max initiate and one for incoming. Max initiate is preferably equal or lower than max incoming while max incoming is the actual max connections per torrent. Perhaps adding a max connections (over max connections to peers) dedicated to seeds is doable.

ML

One size has to fit all in this case. You cant block bad behavior if anyone can change their behavior at will. Talk about damaging the swarm :x

Chaosblade, please explain how it can be damaging to the swarm. It's not obvious to me. While you're at it, think of something that could help me, you and the swarm, all at the same time. All this while preventing bad behavior from other peers connected to you and me.

Also, please convince me that one size can fit all. I mean all users, all configurations, all preferences, all connections, all types of swarms, everything. Since you say that one size must fit all, it must include all these different situations.

As an example, I'd like you to convince me that global max connections, max connections per torrent and upload slots, max upload speed, max download speed, can all be set at the same value that will fit all.

ML

In the sense that everybody have the same rules for the game. If you change the rules to fit you, Others gets hurt in the process.

A choker is neccessary, but a user-configureable choker may be a bad idea.

A configurable choker shouldn't allow choker settings that would also choke your current upload settings. What this means is, you cannot set the choker's minimum upload slot speed higher than your upload slot speed. Otherwise, someone with upload slot speed of 1 KB/sec could snub every peer that uploads <5 KB/sec to them.

Likewise, the choker shouldn't allow settings below or above reasonable values. This should prevent users from using settings that hurt them or the torrent swarm badly.

If no configureable choker is added to µTorrent, then a basic choker should always be in effect in µTorrent. This is what happens if there isn't one:

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

It is terribly unfair that 1 peer has downloaded from the person without returning appreciably anything. (2000 to 1 share ratio!)

The basic choker would make peers that upload <0.5 KB/sec to you targets of your upload bandwidth only via optimistic unchoke if there are more peers connected to you than you have upload slots for that torrent. They should be able to escape that condition if they upload more than you upload to them. However once you upload a chunk back to them and their conditions don't improve they should be choked again. This choker condition should only go into effect after you have uploaded more to a slow peer than the larger of the 2: 1 chunk or 2 MB. This is to insure you are not unfairly ignoring new peers with nothing to share. Plus, you would end up giving back a roughly equal amount to anyone who gave to you ...however slowly they may have given it.

In fact, don't count seeds connected for any rule that controls the number of connections. The more seeds are connected to me, the better.

You may think it's "better" to connect to more seeds, but it's VERY bad for the torrent if many try to connect to every seed. In big torrents, the seeds would quickly hit max connections and late arrival peers would have no seeds at all to connect to. This is what can happen when 1 peer gets unfair advantages via connecting to every seed and selectively grabbing peers:

http://img384.imageshack.us/img384/4989/whyproxysrule4zb.jpg

from this thread:

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

This isn't helpful for the torrent. Seeds should be the sources of last resort. If you cannot handle connecting to more peers due to low upload or download bandwidth, then you don't need to connect to every seed you can find either! Therefore, there should be no differentiation between seed and peer for max connections. This too might be exploitable, but it can only be exploited by someone who manually disconnects+blocks peers so their connections are all or mostly seeds. µTorrent should not have a feature to allow us to exploit this automatically.

Once your client goes from peer mode to seed mode, any remaining peer that uploaded to you more than you uploaded to them should be given slightly preferential treatment of your upload bandwidth till 1:1 condition is met. This will be favoring good uploaders which are neccessary to the function of the torrent ...without penalizing everyone else appreciably. That would also decrease a super-leech's ability to grab an unfair chunk of a seed's upload bandwidth.

A punish leecher option might be worthwhile as an extreme choker. Once a peer has received more than a fixed amount (1 chunk or 2 MB?) from the current user AND has more chunks of the torrent than the current user AND has not uploaded to the user in >2 minutes despite piece requests AND has uploaded less than 1 chunk to the user...then snub them hard. They shouldn't even receive optimistic unchoke. This snub should end any time the "leecher" no longer meets all those conditions.

I think I agree that it must not allow the user to set it so low or so high that it either hurts him or the swarm. Even if I agree, I'm not so sure it will make a difference. For over a week now, I'm in the habit of setting everything so that I can give at least 1kB/s per peer connected to me over time and I reduce conns per torrent when I'm finally seeding so that I can give faster to fewer peers.

For example, I usually upload at 65kB/s so I set 65 conns per torrent and 10 upload slots. That works out to 1kB/s per peer over time and 6.5kB/s per upload slot. When I seed, I usually reduce conns per torrent to about 25 because that's a hot number for the inactive/disconnect cycle with 10 upload slots. Also, I upload at my max capacity to reach my S/R as quickly as I can and that's 100kB/s.

I currently prefer the private tracker so even if there's a few leeches, it's not a problem with all the other excellent peers I can connect to. Public trackers are another matter altogether and that's where a choker comes in handy.

As with the current settings (network, torrent, seeding, etc) a user can set to match his connection, preference and the current torrent, a choker has to allow the user to set it for the same reasons. The user must also have the ability to turn it off and let the other normal functions do their work.

uTorrent already has a kind of choker with the inactive/disconnect function but it does not prevent leech behavior because there's no provision to discriminate between good and bad behavior from other peers. I already suggested that the choker be run only for specific peers that do specific things on a consistent basis. Let the normal functions run their course, watch for leech behavior and if a peer is deemed to behave as a leech would, then run the choker on him but only after all normal functions have run at least until their own timers have run out.

A choker could help all peers in a swarm by forcing one peer with too many connections per torrent by simply choking it and after a while disconnecting it because the choker has deemed this peer to be inactive because of too little trade over time or no trade at all. This peer would then have one less willing peer to leech from and would continue its thing on other peers. All peers that discriminate against this leech would eventually conclude the same thing my client has concluded and he would be left with much fewer peers to leech from. The result for him would be a reduced number of willing peers therefore an increased amount of bandwidth for each of those peers that are still willing. The result for the swarm is pretty obvious at this point.

It's a simplistic evaluation of what a choker could do but it's still valid, I think.

Even if there's a possibility that one peer will try to snub all peers that give him <5kB/s but only give back 1kB/s, that's not possible with a swarm full of discriminating peers. Since the majority of peers will want to TFT if only to get the file as quickly as possible, they'll all be setting their own choker to much more efficient values. They'll also set their upload to a reasonable speed and conns per torrent to a reasonable number to match that speed. This peer with a ridiculously high snub value will simply see his download speed dwindle to a stop because no peer he is connected to can feed him at such a high value over time. Since no peer can feed him, no peer can download from him either because he snubbed them all.

If indeed uTorrent includes a choker in the future, it won't matter if the choker can be set to whatever value because users will find out soon enough what values work and which ones don't. They'll be forced to play nice, not by uTorrent but by other peers.

About seeds being independent from peers with regards to connections. I'm not sure about that, you brought up a good point and I agree with you on that. Nevertheless, I have rarely seen better download speed when I was connected to fewer peers than seeds unless the swarm was only made up of seeds. I think that's because seeds also have more connections than upload slots so they can't upload to all connections all the time. It could still be a problem if one peer (or many peers doing the same thing) is taking up too many connections to seeds that could otherwise be put to better use for other peers.

I suggested a reverse choker that will refuse to download from slow seeds or keepalive seeds. I call them keepalive because that's all they do sometimes.

ML

Torrents and trackers, be them private or public, should not be subjected to the "learning curve" of potentially 100's of ignorant tweakers who use self-harmful and torrent-harmful choker values. There's a reason why much of BitTorrent is automated...it's so uniformity can be expected, making compatibility easier. Vastly dissimilar choker values are even less compatible than vastly different connection speeds. Aggressive chokers could create a haves and have-nots worse than what already exists AND leave numerous peers and seeds alike uploading at less than their maximum because their choker is blocking lots of peers.

"Even if there's a possibility that one peer will try to snub all peers that give him <5kB/s but only give back 1kB/s, that's not possible with a swarm full of discriminating peers."

You can't treat the current conditions as a pure TFT environment. Optimistic unchoke, cheating clients, client favoring one another, just plain buggy clients, and just plain slow clients make the reality a lot more messy. If anything, it helps the opportunists.

A peer which sets HIS custom choker to snub all peers uploading to him <5 KB/sec while only giving back 1 KB/sec per upload slot...would actually get "hurt" little at all and in fact would likely benefit if combined with connecting with as many seeds as possible. TFT finds the best "deal" it can get...which in an environment of lots of <0.5 KB/sec upload slot peers+seeds makes one that uploads equal or close to 1 KB/sec per upload slot SEEM decent. So any fast uploaders that use few upload slots will be latched into quite quickly by this "strategy". If the fast uploaders don't also use a good choker scheme...and most don't...then they won't know there's potentially better uploaders for much longer, since optimistic unchoke spends more time uploading to "new" reconnecting peers than existing peers.

"For example, I usually upload at 65kB/s so I set 65 conns per torrent and 10 upload slots."

Ok, here's my settings and results:

I just discovered last night that my ISP, in its attempt to compete, had raised my upload bandwidth by some unknown amount. So I did some upload testing -- trying to seed about 20 torrents at once near the max upload speed for my connection. I set every torrent's upload slots to 1 or 2 and maximum bandwidth between 40 and 60 KB/sec.

It went horribly. Upload speeds were jumping all around. On average, the value I set was about right...meaning my connection WAS capable of that speed. But in practice µTorrent couldn't hold its upload speed consistantly close to that value. What's worse, when I looked at individual torrents during these conditions I saw they often had 3 or more uploads going at once, with more than half of them running <0.5 KB/sec. Some had 6 or more uploads!

I thought the problem was simply I was running way too many torrents at once or variable overhead traffic was cutting too deeply into my real upload bandwidth. So I reduced upload speeds and stopped all but 4 torrents. Eventually, my separate bandwidth-monitoring program was showing a nearly "flat" upload speed meaning my bandwidth consumption was so far below max that even µTorrent's upload jitters weren't causing occassional spikes over max.

The point at which I wasn't seeing bandwidth spikes more than 50% greater than my connection's max followed by deep

troughs for the next second or 2 was when I cut upload max speed to about 70% of the max speed of the cablemodem connection. These were causing incredibly bad "lag" on another computer I was trying to surf the web and post here on.

But the additional upload slots didn't go away! The upload speed as measured by µTorrent was still so random that µTorrent was always opening new upload slots thinking there was spare upload bandwidth.

Had I set upload speed FASTER than my connection could sustain the problem could have been a magnitude worse, as µTorrent might have opened upload slots till it hit about 10 per torrent. Instead of giving out upload slots at ~0.4 KB/sec speeds, it would be giving them out at <0.2 KB/sec speeds!

One thing reduced them considerably though -- UNCHECKING the additional upload slots if <90% max upload speed. Even with that I was seeing torrents being uploaded to 2-3 ips at once even though I limited them to 1 upload slot. Plus, upload speeds averaged about 1-3 KB/sec below my set value. This was a rude shock -- µTorrent was simply ignoring the values I set.

With all this variability, a custom choker is premature. There are simply too many preconceptions about BitTorrent behavior (even by me!) that may (and probably will) result in horrendously bad settings and results. For the majority of my tests, my own settings would result in roughly half of all peers I uploaded to seeing me as a "slow uploader" that wasn't uploading even 0.5 KB/sec on average!

Seriously, the leech with the <5kB/s choker will hurt. Since the majority of peers can't feed him that fast, they'll be cut. Since the majority of seeds can't feed him that fast, they'll be cut. The choker doesn't discriminate between slow peers and slow seeds, it cuts all peers and seeds that can't feed him below the choker's threshold. The result for that leech is that he'll be cut off from all the reasonable but slower peers and seeds. The result for the swarm is all other peers who set reasonable values for their choker will get reasonable speeds and will match themselves based on their own choker settings.

The purpose of the choker concept is to cut out slow (or slower than x over time) peers and seeds to look for fast (or faster than x over time) peers and seeds to TFT with. That's where the choker concept comes in, TFT. If the client can't TFT with his own choker settings because he can't send back what he asks for, he'll be cut as quickly as he cuts other peers. He can't TFT with seeds but that doesn't matter. Even if the result is him getting data exclusively from seeds, few will be able to feed him at such a high speed and his download rate will go down dramatically. He'll be shooting himself in the foot, so to speak.

If he then wants to increase the number of seeds he's connected to, he'll probably fool around with his choker settings to allow slower seeds to reconnect on the odd chance that they can feed him faster this time. Old slow peers/seeds will be remembered by the choker so they'll be reconsidered as good peers/seeds. Raising the choker cutoff back to 5kB/s at this point will simply cause them to be cut again. Round and round. Even if the seed can't figure out which peer is leeching and which is playing nice, it doesn't matter because this seed also has multiple connections, only a few of which it actively sends data to. No single connection to this seed will be able to get data continuously from this seed. Even in a small swarm it doesn't matter since this seed will be sending data to all connections, not just the lone leech.

The choker must remember old cut peers/seeds so that they don't benefit from the higher optimistic unchoke that they would otherwise benefit from. In fact, the client must not allow those old cut peers/seeds to reconnect unless there's no other choice because the swarm is too small.

By setting the choker to cut off <1kB/s peers/seeds and by giving at least the same or more back, the client will play nice and defend itself against abusive peers. Doing the reverse will get this peer cut. It's as simple as that.

I've read numerous times how BT works best when the connection works at 1kB/s or more. Lower than that and it starts falling apart. Without a choker, there's no provision to prevent behavior that allows the connection to fall below 1kB/s. That's the current situation.

In my case at 65kB/s upload limit, I can feed 65 peers at 1kB/s over time. With 10 upload slots, I can feed each upload slot at 6.5kB/s. This means that any peer I'm connected to who has a choker cutoff of <1kB/s will TFT with me. If I truly want to play nice, I reduce conns per torrent to give back more than 1kB/s to each connection over time. In a swarm with many seeds, I can increase the number of connections so that I can still give back at least 1kB/s to each peer over time while getting more from the seeds.

A choker can't solve all leeching problems but it can reduce generalized leech behavior by localizing good behavior.

There's no need to reeducate a multitude of users to the choker if it includes a wizard with known working reasonable values for the type of connection, upload speed and preference of the user.

ML

Holy shit that's a long post.

I have to say I'm in agreement with chaosblade here. I really don't think it makes that big a difference to warrant basically ignoring the way the protocol works.

A basic automatic choker though is still neccessary, because at least on public torrents we're dealing with cheating clients, buggy clients, and very slow clients.

However it has to be a very forgiving choker -- because as my tests showed even my connection LOOKED slow due to µTorrent build 406's inability to obey the settings I gave it.

As far as im aware uTorrent does have a choker, just not configurable in any way.

What do you mean by "inability to obey the settings i gave it" ?

About reconnecting peers getting a bigger piece of the optimistic unchoke cycle. That's a good thing that can be abused if the client doesn't remember old peers for what they are. It's a good thing to allow new peers to get data quickly. It can be abused by clients who reconnect frequently to get a bigger piece of the pie without paying the TFT price that normally comes with it.

I want those peers to be discriminated against. I want those peers to not have the advantage of the optimistic unchoke cycle. I want those peers to be remembered for what they are and put back into the regular unhoke cycle. It won't affect new peers since they are new but it will cut out bad peers that abuse this function. An argument can be made not to discriminate against old peers that have bad connections that cause frequent disconnects/reconnects but it doesn't hold water for the simple fact that it's not my responsibility to make sure other peers have good connections, it's theirs. If they don't fix their connections, that's their problem.

It could be as simple as giving the benefit of the doubt on one disconnect/reconnect attempt. After that, it's back to the normal optimistic unchoke cycle. I remember you, you got cut for whatever reason so I'm giving you a second chance, if you blow it again, you get back in the pile of regular peers.

This function isn't part of the choker idea but since it could be a problem (it already is a problem) as Switeck observed, it must be addressed if a choker is added. And since it is already a problem, it must be addressed anyway.

The choker idea is a good idea but if it can't be implemented because of current problems, it's not a reason not to implement it instead it's a reason to fix the problems first. The choker idea is there to fix certain problems that exist, not to be vulnerable to those same problems.

Switeck, how about this. Either/or situation for an automatic choker (not configurable by the user) that runs only after all other normal functions have failed to make sure the client TFT's with good peers. The choker runs only if a peer has sent less than either 1kB/s over time (the normal inactive/disconnect timer interval or an additional interval after the first normal interval) or less than one complete block or piece over time (same interval here) and I sent it data though optimistic unchoke during the same interval. The choker remembers old peers and the reason they were cut, for whatever reason, it must act accordingly. Also, the client can't have more connections than he can feed at least as fast as the choker requires based on the same choker rules (1kB/s over time or one block/piece over time). Once a peer is choked through this method, it is considered inactive for the disconnect interval and eventually gets cut once the interval runs out to leave room for potentially good peers. The client plays nice and is forcing other peers to play nice as well. Just like when the swarm is too small, no peer is cut but with a choker, they'll be cut out of the loop if they don't play nice. Large swarms don't have that problem.

The only thing I see wrong with the above is the lack of control the user has over the choker. Apart from that, it looks like it can do the job. If you can think of a situation where it can go wrong, I'd like to know so we can discuss it and find a solution.

Chaosblade, how does uTorrent defend itself against leeches? That's what a choker does and I don't see any function within uTorrent that does that. If you refer to the imposed limits on the uTorrent user that prevents him from setting too many upload slots or from setting his upload speed too low, that's no protection against other peers. Perhaps you wish that uTorrent remains vulnerable to an aggressive client that you currently use? I don't know how you can defend your position but I have doubts as to your intentions.

Alright, let's get things straight. All users are not equal. All clients are not equal. BT doesn't work properly all the time. BT can be abused intentionally. Not all clients can protect themselves from this abuse. In fact, those that can't, are abused.

Here's the kicker, once you put power in the hands of the user, he will use it. Try BitComet and you'll see what I mean. The user has the power to mess everything up and he does that just fine without my intervention. By the same way you can put that kind of power in the hands of the user, you can also put him in control by giving him the power to defend himself from abusive users. Once you do that, the first type of power completely and utterly disappears since it just doesn't work anymore because we all have the power to defend ourselves.

You may think that putting that kind of power in the hands of a leech is a bad thing but check this out: I have the same power I can use against him. The result: I win, he loses. It's as simple as that. Try BitComet again and you'll see what I mean. What, do you think I'll be the only guy on the block that can defend himself? Once the word gets around that we can defend ourselves from BC users (or any other abusive clients), what do you think will happen to BC or the other abusive clients? Their power will be null and void. No use trying to get that hard to get torrent with BC now because everybody will have the power to defend themselves. We'll have no choice but to play nice on a global scale.

You wanted everybody to play by the same rules. A choker does just that even if it can be set to a user's liking that may not match yours. Preventing the user from setting it to his own preference doesn't make a difference in the end since he will be forced to set it to reasonable values that force him to play nice with other users even if he can do whatever he wants with the choker.

What if you don't allow the user to configure the choker? What if that user can't make it work with the imposed limits? What happens then? He'll be shit out of luck and will have to use a different client. Unless he can turn it off. Who says what works and what doesn't for this particular user? Do you? Do I?

Chaosblade, can you convince me that max active torrents, global max connections, max connections per torrent and max upload speed can be set to a single value that will fit all? What is it if not changing the rules to fit one user?

ML

What do you mean by "inability to obey the settings i gave it" ?

So I did some upload testing -- trying to seed about 20 torrents at once near the max upload speed for my connection. I set every torrent's upload slots to 1 or 2 and maximum bandwidth between 40 and 60 KB/sec.

...

Upload speeds were jumping all around. ...individual torrents during these conditions ...often had 3 or more uploads going at once, with more than half of them running <0.5 KB/sec. Some had 6 or more uploads!

...

I reduced upload speeds and stopped all but 4 torrents.

...

But the additional upload slots didn't go away! The upload speed as measured by µTorrent was still so random that µTorrent was always opening new upload slots thinking there was spare upload bandwidth.

...

One thing reduced them considerably though -- UNCHECKING the additional upload slots if <90% max upload speed. Even with that I was seeing torrents being uploaded to 2-3 ips at once even though I limited them to 1 upload slot. Plus, upload speeds averaged about 1-3 KB/sec below my set value.

I've since continued my tests. My upload speed tests out right at 380 kilobits/sec. If the connection is doing nothing else, it should be able to sustain at least 38 KB/sec. But the upload 'jitter' was still great enough at that speed that sometimes it'd spike above 42 KB/sec or fall below 30 KB/sec. The average always worked out to be about 1-3 KB/sec below what I set. Setting upload speed higher aggrevated that problem, as I was nearing theoretical upload maximums as well as pratical maximums.

The open new slots if below 90% of upload speed is looking for too small a variation to merit. End result is often far more upload slots than can be managed...and average upload slot speed barely worth measuring.

When not allowing additional upload slots if not at max upload speed, µTorrent was often uploading to 2-3 ips per torrent even though I set upload slots to ONE. This thoroughly messes up my calculations of average upload speed per upload slot. Strangely, of the 2-3 ips it's uploading to, 1 is usually going pretty fast (like 3+ KB/sec) but the others often are going at 0.5 KB/sec or less. I can understand if 1 of the "extra" uploads is the optimistic unchoke...but what's the other one/s doing?

Here's an example pic:

I had upload slots for that single torrent set to 4.

Use extra upload slots if <90% upload speed is UNCHECKED (not shown in pic, sorry!)

Global Upload speed was set to 40 KB/sec...pic shows pretty close to that for a change, often it's bouncing between 35-39 KB/sec.

At the time of the screenshot, I was uploading to 15 different ips.

Is the use extra upload slots always on despite being unchecked? (meaning...broken)

sort by flags and look at u/U, change update interval to 500ms

you might see 5 because of optimistic unchoke

down speed and up speed show average speeds.

I did, and what you said is basically correct -- only 5 ips are technically "U" flagged.

However the average upload speeds are what I care about.

I don't want µTorrent upload-jumping between 10+ different ips every second, even if it DOES mean it's only doing 5 at once.

it won't choke a client for less than 10 seconds of activity, but since there's up to 5, it can look like it's doing it every second.

And like I said, the speeds are averaged, so it shows a speed display long after you choked them