Uneven speed capping

[Inf]

At the attached image the left graph is the emule upload traffic capped to 40kbytes/second.

At the right is the ut, capped at the very same speed.

This issue becomes important when you want to let the ut upload at the speed very close to your max, while still keeping the connection usable.

Anyone got a solution ?

NOTE: I tried to setup both emule and utorrent so the connections count, total upload slots etc will be more or less the same.

[Greg Hazel]

It's all about averages. The average uT uses is over a longer time period. You'll notice eMule fluctuates as well over a smaller time period.

It could be made smoother, I suppose. What is the time interval of this graph?

[Inf]

The entire graph is about 2 minutes 15 seconds give or take 5 seconds. The average BW on both graphs is approx 40kbytes/sec + some overhead, as it is supposed to be.

Of course emule fluctuates as well, you can even see it on the very same graph.

And, as it seem, its not just about averages, its also about peak deviation from that average and the time it stays near that peak. If the peak is high enough and long enough, it WILL screw up ACK-ing the data on anything currently downloading. And since the recovery after this isn't really immediate, there is a chance the next peak will come even before the ACK stream is back to normal, ensuring the connection stay slowed down to hell.

I am not trying to go into the math part of a TCP connection or trying to really prove anything.

The fact is, 55kbytes/sec cap on my connection in emule - network keeps running pretty smooth. The same cap on ut - network is totally slowed down.

[Switeck]

If you use imbalanced/ridiculous settings in µTorrent, you'll get spikey speeds below and above your limits.

Generally, this is caused by extremely high connections, half-open connection rate, or just too many torrents at once.

[Inf]

Switeck, i don't use any insane settings (80 connections, both global and per torrent, 20 connections per/second max, 30 max half-open connections, 3 torrents running at the same time, for 1.5/0.5mbps connection those settings are very modest and far from insane). The settings in emule where very similar, actually, a little bit more aggressive. And i already tried to lower max half-open connections to the default, 8, before replying, and got no improvement.

[Switeck]

I personally think 30 half open connections at once on anything less than 10 megabits/sec symmetric is overkilled, doubly so if you're not firewalled.

...But if the problem persisted with a half open rate of 8, did it seem to improve any as you lowered that to 4 or even 1? (...once you have made at least 10 connections that is.)

Have you checked in the Peers tab/window to see if there's major bursty-ness to various ips you're uploading to?

I've seen all kinds of bursty-ness myself if I'm uploading to marginal downloaders (people who have their own upload maxed out, bad ISPs, etc...) -- in those cases, it really cannot be avoided.

Even a too-high or too-low upload slots value can prevent smooth uploading. For me, the "sweet spot" seems to be about 3-10 KiloBYTE/sec per upload slot.

(Note: I mean total upload slots, not just upload slots per torrent.)

[Inf]

First, half open connections, or connection count in general, add some overhead, but we are talking about less than 200 connections total here (80 + 30 worst case, thats if ut really counts half open ones separately). Come on, get real. Even if you initiate 200 connections at the very same time, you would hardly spot it on that graph. SYN packets are not that big.

As for all other things you mentioned, you do get that it shouldn't be like that, don't you ? I can understand why those reasons may cause the speed to fluctuate downward, but there is absolutely no real reason for it to deviate upward for periods of times long enough to affect the connection. And as you can see, the average is clearly on the cap i set and it fluctuates both ways.

A final note, when i was asking for solution, i kinda hoped to discover some settings that control the capping algorithm, especially things such as how often it samples the speed and how fast it reacts.

I don't know, maybe i am wrong, but it kinda looks to me like oscillations caused by the control algorithm feedback delay set too high or something very similar.

[Smoovious]

I know it looks that way, but you're wrong.

Look into it a lot deeper, there's a great deal you haven't taken into account yet.

-- Smoovious

[Switeck]

Get TCP View.

Often it's the sheer number of failed and half-failed connections that tend to accumulate with high half open connection rates. These wouldn't be counted anymore by µTorrent, as it already gave up on them and handed them off to the Win OS to properly close.

It is true bandwidth-wise that 200 connections shouldn't be a problem. But for whatever the reason, most consumer networking hardware AND software really cannot sustain the loads.

There's been a few other posts before about µTorrent overshooting its speed limits, and by more than a couple seconds. Got some pretty pictures to back it up too. It almost seems like the designer(s) wanted the speed limit to be the average rather than the maximum.

Play around with the settings, and you'll probably find µTorrent to follow closer to the limits or less close...and maybe you'll find some rhyme or reason that I'm still guessing at too.

But I just use the program like you, I don't really have any workarounds except to set your connection maxes at less than maybe 50 and hope that helps.

[Ultima]

Heh I think a subtle point that's being missed here is that this isn't a graph from µTorrent itself. It's very often been the case that speed measuring applications measure different speeds than µTorrent itself is showing, and that's the point Inf is trying to get at (sorta). µTorrent is showing everything fine and dandy in terms of the Speed graphs in µTorrent itself and the speeds totals in the statusbar, but when the rates are looked at through external applications, it reveals a very different trend than seen in µTorrent.

I'm pretty sure that Inf (a veteran user of µTorrent) has everything set up properly, so the possibility of the spikes coming from all these nooks and crannies like half-open connections and max global connections should be pretty low.

[Inf]

I know it looks that way, but you're wrong.

Yea, right. There is absolutely no way the mods are wrong. The op/mod/etc is always right rule. I really think i AM looking deep enough.

Get TCP View.

TCP View is totally unrelated.

It is true bandwidth-wise that 200 connections shouldn't be a problem.

Please note that i am talking purely bandwidth-wise, and this graph can ONLY show you the bandwidth usage, nothing else. Also note that utorrent causes no side effects on my system at those particular settings, so again, we are talking purely bandwidth-wise here, but NOT just about average bandwidth.

that this isn't a graph from µTorrent itself

µTorrent is showing everything fine and dandy in terms of the Speed graphs in µTorrent itself and the speeds totals in the statusbar

True.

PS: If anyone is going to keep replying to this thread, please read the first 5 posts carefully before doing so. I am really starting to regret i posted it. And btw, Ultima, 10x for supporting me.

[Switeck]

Ok, let's say I agree with you that it is real, it is a problem, and it may be µTorrent's fault.

In searching for the underlying cause/s, "It is true bandwidth-wise that 200 connections shouldn't be a problem." [but as you already said, something is!]

...which follows "But for whatever the reason, most consumer networking hardware AND software really cannot sustain the loads."

So that means you're probably right but the cause/s probably aren't as simple as being able to fix µTorrent and it will magically solve itself.

Can you test on other equipment to see if µTorrent shows similar uneven speed capping on them?

[Inf]

No, i can't test it on other equipment any times soon. But i gave you a reference (emule), working on the same equipment, under very similar conditions. In addition, you can take my word for it, i AM familiar with my equipment limits, and i am not anywhere near stressing it.

[Switeck]

Then it's up to the BitTorrent developers to be able to duplicate the conditions AND agree it's a problem they can/will fix.

Currently, it looks like no-go on both accounts.

Do take a look at connection activity levels using something like TCP View. Your settings may be correct, but even if it's remote...maybe there's a nagging low-level problem that only crops up under strange conditions. Or a DoS attack, even an unintentional one, such as trying lots of very active torrents...all the old+slow ips (and seeds) may be retrying your connection very quickly and regularly even though you long-ago quit those torrents. Knowing that's NOT happening means it'll probably be easier to reproduce.

I'm looking too, but my bandwidth graph in µTorrent seems very smooth.

[Inf]

Switeck, in my case the internal graph utorrent shows also seems very smooth. But thats only because it does much more averaging that the external utility.

[kalmi]

This can be observed even by just using Windows's task manager. :/

(And yes, i do have rate limiting turned on for transport overhead.)

But why does it being uneven even matter?

Imagine the following scenario:

You set uTorrent's upload rate to 40 Kb/s and your internet connection's maximum upload speed is 50 Kb/s.

Your torrent client will never send more than 40 Kb per second,

so your average download rate will be 40 Kb/s as expected.

All seems fine, right?

The problem is that never sending more than 40 Kb per 1 second does NOT imply

that the client will never send more than 20 Kb per 0.5 second or 10 Kb per 0.25 second or ...

But, why is that a problem? We only care about averages, right?

No, you want your Internet to stay performant, that's why you set up rate limiting in the first place.

Those spikes in the graph do saturate your pipe every once in a while,

and they do degrade the performance of interactive connections (ssh, games, etc...).

I am just trying to get across what Inf said:

This issue becomes important when you want to let the ut upload at the speed very close to your max, while still keeping the connection usable.