bt.auto_ul_* - what are these settings exactly do?

[V@no]

Hello!

I've been trying find a detailed explanation on the bt.auto_ul_* settings

Can someone explain what each setting does?

Thank you.

P.S.

If its easier here is the list currently available in v1.7 build 3341:

bt.auto_ul_factor

bt.auto_ul_interval

bt.auto_ul_min

bt.auto_ul_sample_average

bt.auto_ul_sample_window

[segate]

bt.auto_ul_factor: This option sets the portion of the largest reading to use for throttling. It is interpreted as a percentage, so please enter it as such.

bt.auto_ul_interval: This option controls how often µTorrent tests the upload rate for setting the upload rate limit automatically. Every time this interval passes, µTorrent disables the upload rate limit and lets it run while sampling the rate. This option is interpreted in seconds, so please enter it as such.

bt.auto_ul_min: This option determines the smallest upload rate µTorrent will use while in auto-uplink throttling mode. If the sampled average is less than this value, µTorrent ignores the sampled average and uses this value instead. This value is interpreted in bytes per second, so please enter it as such. Note that if this value is too low, the automatic upload rate limiter might possibly set the upload rate to a level low enough to trigger Download Limited mode.

bt.auto_ul_sample_average: This option sets how many seconds to average the amount of uploaded data over (sliding window).

bt.auto_ul_sample_window: This option controls how long each sampling run will take. It is interpreted in seconds, so please enter it as such.

if you want see more ,download this

http://download.utorrent.com/utorrent-help.zip

[Myros]

Segate, thanks for the link !

Rather helpful

[V@no]

Thanks for the explanation and for the link.

Still its I'm not quet understand how to use them...

My problem is that when I download a torrent with lots of peers/seeds and the upload rate to that torrents set to 1kb/sec, my upload speed (on the torrents that I seed) drops significaly to less then 1kb/sec, instead of 40...no metter how many peers globaly/per torrent I set in the settings this issue is always present. The upload speed I'm talking about is not only showed by the uT, but netmeter is also reporting 1/4 of the max possible, which means the downloading torrents dont take the all upload bandwidth. As soon as I stop the downloading these torrents, upload speed jumps to 40kb/sec. Note, that it ONLY happens with torrents with alot of seed/peers.

So, I figured, maybe these settings are causing this?

[Ultima]

Those options most likely have nothing to do with your problem, as they affect autouplink throttling only. Can you describe your problem a bit more clearly? I'm having some trouble following your description (are you talking about multiple torrents slowing down? only that single torrent?).

[V@no]

Ok, lets try.

The setup:

global max connections: 1000

per torrent: 300

upload slots: 4

download cap: unlimited

upload cap: 40kb/sec

in the queue 3 torrents: 2 seeding and 1 downloading

the downloading one has available 1000-1500 peers+seeds, but connected to 200 as per settings and upload speed for that torrent capped to 1kb/sec.

the 2 seeding torrents have available 300 peers total, but connected to 50

Now, if all three torrents are active, the total upload speed is less then 10kb/sec, once the downloading torrent stopped, the total upload speed jumps to 40kb/sec.

If I increase the upload cap for the downloading torrent, it will use as much upload bandwidth as it can.

Set higher priority on seeding torrents (or lower on downloading) have no affect while the downloading torrent is active.

[Ultima]

Well, you're not even following the Speed Guide's instructions properly -- that's for sure. Run the Speed Guide (Ctrl+G) in µTorrent and select the proper upload rate.

[V@no]

These exact settings I've been using for a year or so in BitComet, I've never had any kind of issues exept for my router needed to be rebooted time-to-time. If you are saying that in order to achive most perfomace in uT we have to stick with the predefined settings for our connection (which in my case would be: 47kb/sec upload limit, 250 global connection, 90 per torrent, max active torrents 3 (huh?) max active downloads 2 (wtf)), I'd rather then stick with something less stable but more productive (speed wise) *cough*bitcomet*cough*...

All I'm saying, there is something wrong with uT if its behaves the way I've described above, IMHO... because other clients don't suffer that problem..

[DreadWingKnight]

Actually, bitcomet lies cheats steals and otherwise fucks over swarm speeds for its own benefit.

The predefined settings are a baseline to work from.

http://utorrent.com/setup_guide.php will help you optimize your settings for your connection.

Connecting to more peers slows you down more than it speeds you up. You're eating your connection alive with protocol overhead.

[Ultima]

You're sorely mistaken if you think more communication overhead means more speed or "productivity."

[Switeck]

I have already posted in great length how BitComet's known cheating is often VERY counterproductive even for itself.

BitTorrent isn't a marathon race, so tripping the other runners so you can "win" is really stupid.

(By this I mean screwing over the other peers in the hopes of getting slightly higher download speeds for itself.)

[V@no]

You guys are missing the point, I'm talking about the upload speed, not the download speed...there is no "race" involved...What I'm trying to explain is that uT some how messes up the upload stream when there are alot of peers to connect, even if you restrict that very torrent to 1kb/sec upload it still messes up the other seeding torrents. And its not because the torrent with lots of peers taking up all available slots or connections, and other torrents can't connect to other peers, its not the case here. BitComet I only mention as an example where the same settings works, so its not the system's fault, but the client's...

[Ultima]

And we've been telling you that overloading your connection with those settings you use will cause problems you see. We, who have been troubleshooting these exact problems for well over a year now.

If you think µTorrent is the only client to suggest such "low" settings, look at Azureus' recommendations -- not all that different, but a far cry from your idea of what "good" is.

[Switeck]

There is a very real bandwidth cost just to continue to stay connected to an ip via TCP/IP. This is because a "keep-alive" packet has to be sent every few seconds. BitComet may either not show this amount in its total upload speed...or it may be reducing the actual torrent upload speed to keep upload BANDWIDTH use under a set amount...though it's unusual to describe bandwidth use in KiloBYTEs/sec.

So having 200 connections active on the download torrent and trying to force that torrent to only use 1 KiloBYTE/sec upload bandwidth is simply impossible. Connections will spontaneously break. µTorrent won't do that...it'll try to use enough bandwidth to maintain the connections, even if the amount is stupid for no more upload speed being offered. So as you increase upload speed on that torrent with 200 connected peers, it grabs far more upload bandwidth than you expected...swamping out the other torrents you have going.

Have you also checked µTorrent's advanced settings?

[funchords]

BitComet uses a dynamic slot and dynamic independent slot speed algorythm. uTorrent uses a static slot (with additional slots allowed if bandwidth limits are not reached).

Both are valid.

BitComet uses an algorythm that is very similar to BitTyrant, and like BitTyrant (in default mode), it gives back any excess UL BW to the swarms that it is in. It's not cheating -- in fact, this is an advancement.

Both BitComet and uTorrent rewards good players and penalizes stingy uploaders right in the swarm -- but BitComet does so in an intelligent way.

BitComet will give a reciprocator more/less upload depending on what the reciprocator does in response. The excess bandwidth is then used in another slot to find another good reciprocator. This is why BitComet has so many upload slots. BitComet follows the BitTorrent wire protocol, but follows the BitTyrant behavior.

uTorrent follows the BitTorrent wire protocol and follows the classic BitTorrent behavior, using Optimistic unchokes to find reciprocating peers. The UL is balanced to all of the unchoked peers, evenly (if they can take it).

BitComet's scheme does let it run more downloads at once, because heavily seeded swarms are not going to get many upload slots. uTorrent can do this, but it requires manual intervention. With that manual intervention, the small advantages that BitComet has left really will only benefit the user who is in a crummy swarm with a lot of slow peers.

As a technical downloader, BitComet is fantastic. However, it's a crappy seeder (among the worst of class, based on my testing). It also has a one-size-fits-all installation experience, which usually means that new users who don't know better have the wrong settings to begin with.

Switeck -- all of my testing has been on BitComet 0.90 and 0.91. So far, the previous complaints largely do not apply to this version (apparently they did a major engine overhall around the 0.8x timeframe). I'm about to write a paper about my testing, so if you have any relavent information concerning these later versions, please let me know.

[Switeck]

µTorrent's upload slots do not run at the same speed for me. Often, I see 1 peer downloading from me at 1-3 KiloBYTES/sec while others may be at 5+ KiloBYTES/sec. I OFTEN see the majority of my upload bandwidth going to the 1 peer that's giving me the biggest download speed. Tit-for-tat seems to be working ok, except for the occasional exploiter. µTorrent will in fact decrease the number of used upload slots per torrent if it can't reach a minimum average upload speed PER upload slot. This behavior cannot be disabled for the same reason "download limited" cannot be disabled.

BitComet's dynamic slot and dynamic independent slot speed algorithm WOULD be valid if it wasn't just plain BAD.

I tried to test BitComet v0.91...BUT...

Even when I only had 3 seeding torrents active and less than 40 total connections and an upload speed max set to 42 KiloBYTES/sec, I was uploading to various ips at 546 BYTES/sec or 1 KiloBYTE/sec. That's breaking compatibility with the BitTorrent protocol at its most fundamental level (the TCP/IP level)...and failing to propigate whole pieces to other peers in a reasonable amount of time, which can quickly result in unseeded "dead" torrents.

Since there is no direct way to avoid the hair-splitting of your upload speed between almost all the connected peers on every torrent (because you cannot manually limit upload slots per torrent), the only thing you can do is limit the number of connections per torrent to 10 or fewer if you want to be even a marginally useful sharer.

In short, there's no GOOD SEEDER SETTINGS for BitComet v0.91!

As a technical downloader, BitComet is poor. The only way one can expect to see decent download speeds in return for the upload speeds you're giving is if you manage to connect to MANY seeds at once or many lightly loaded peers with very large upload speeds. The latter is a matter of luck, the former is leech behavior. Neither is swarm-friendly behavior.

BitComet often fails to identify the port address for peers and seeds and propagates this mistake through peer exchange and probably DHT as well. I see this alot in µTorrent's Peer list...as peers ending with :65535 port address. This forces peers and seeds on torrent swarms to make more connection attempts (or discard all peers/seeds supposedly using port 65535) on a torrent to achieve a reasonable number of stable connections.

BitComet's default setting of 10 tasks/Torrents at once qualifies as hostile because most people have internet connections with less than 1 megabits/sec upload bandwidth. The (disabled by default fortunately!) auto-starting of MORE torrents if download speeds fall below a user-set amount adds to the poor performance of many BitComet clients.

BitComet's default upload speed of 10 KiloBYTES/sec certainly didn't win any "brownie points" with me. Settling for a very low default upload speed may eliminate many complaints of BitComet causing web surfing slowdowns, but it won't help torrents get to other people very fast.

BitComet would be better served with holistic settings changes on first run based on how fast you say your connection is. It would also be worthwhile if the settings could be set "aggressive", "normal", or "conservative"...since many computer+networking setups cannot handle the load even if the internet connection is fast.

In conclusion, BitComet's dynamic upload slots holds it back and makes it hostile towards true BitTorrent clients. You cannot avoid this behavior short of "stupid" settings. The default settings are very bad and there's no set-up guide with the program to give any guidance on good settings to use.

I will not do more than mention that the program ran out of system resources and crashed very quickly on my computer, as that could be a problem with my computer rather than BitComet v0.91.

Even if I did not know about µTorrent, I would not recommend BitComet to others.

[the_orange]

Sorry if this question is lame but in my uTorrent ver. 2.0.3. I don't have these options while i need them SOOOOOO much. Please tell me where did they go T_T And in which version were they still available >_<

[DreadWingKnight]

So you're asking us about unsupported versions and which unsupported version to go to in order to get settings that you don't actually need, but just want really badly?