Good settings Guide

Hi Gang, Rigmar Radio here, long time user of Vuze or Azureus as it still is once you get rid of the user interface for IQ Zero's who don't know where to go for content sigh...

You can do a lot with Azureus but you need a powerful PC with fast CPU and memory and it really is for the advanced user when all is said and done. Few now use it as they don't know that you can switch off the VUZE interface with a few mouse clicks and get back to the advanced Azureus view we all knew and loved.

In my opinion Azureus is the most advanced bit torrent client in the World today, and possibly the most difficult to learn how to use.

I am a frequent uploader of copyright free Promotional Video's on the demonoid site where I have the username towerelect and I have noticed over the years that the most popular bit torrent client by far now is µ Torrent. and I am rather upset at the VERY POOR download speeds most µ torrent users show when taking stuff from me.

So I have downloaded your client and seeded and downloaded a little so I could learn it's ways and perhaps help you all here improve your download speeds, especially when connected to my swarm where I attempt to upload at speeds in excess of 150 Kilo Bytes (kB) per second. Few µ Torrent users can take it.

Please accept my apologies if this topic has been covered before:

µ torrents base setting would appear to be way too generous by far for the bandwidth given. In my experience with a T1 internet connection (2 cable modems via a load balancing router) 800 connections in total is WAY too many and will result in your speed dropping if you also use the default setting of 15 torrents running at the same time (varies with you bandwidth settings). The total number of connections between all your seeding torrents should not be more than 450 unless you are in the top 10% of the World bandwidth wise (which I am right now)

May I strongly suggest here that when downloading you only run at the very MOST one seed or if it is a very good swarm you are downloading from NO SEED at all as you will need all your available upload bandwidth to feed the swarm and by doing so keep your download speeds way up high.

If you run more than one download and more than one seed at the same time then your speeds will be very poor, that is it and that is all. Simple really but I am so fed up with peers who are taking my stuff at dial up speeds this has to be said and on this forum. Thank you for your kind attention.

oh try speedtest.com for you bandwidth checks, great site and loads of fun.

That speed puts me in the top 10% of users in North America and in the top 5% of the World but can you take 150 or more on your downloads sigh.....?

Kind regards, Rigmar Radio.

Thank you for your post, and a little self promotion never hurt. What do you think of the community--well, Switeck-driven settings found @ http://forum.utorrent.com/viewtopic.php?id=34259

Thanks for the link, Yes they are far more realistic, what a pity that few downloaders seem to stick to them. Some times I need 15 peers to take 150kB from me which is rather sad and when I see the average speed way down as well it is clear to me that they are not uploading or downloading much from the swarm either. We need a mass education drive on all popular Bit Torrent client platforms. I still have a lot of reading to do on this forum.

Rigmar Radio

It's an even bigger pity that seeders don't use better settings.

While downloading, connecting to 50 peers+seeds "works ok"...especially if most of those are seeds.

But once you become a seed yourself, it's nuts to be connected to 50 peers! It's not practical to upload to more than 4 at once (upload slots=4) for the majority of connections.

I'd like to see where BitTorrent works well with just 10 connections.

Yes that is so true. Only seed one or at the very most two torrents if they are new and you are starting them off as you will need all your upload capacity to feed the swarm. The number of slots you allow depends a lot on the swarm and how much (or more than often how LITTLE) kB per second each peer can download. I find that often I have to open 15 slots so the swarm can take 150kB, my maximum upload speed during the day. At night and off peak I can go to 160kB but that is really pushing my connection to the limit.

I have 26 torrrents on Demoniod which I started and if I seed them all, then obviously I have to reduce the slots to just 2 or 3 and the number of connection on each torrent to just 10 or again I will max out my upload bandwidth. I find the new auto speed in Azureus very, very good indeed now and often leave in in charge of the upload speed when I am just seeding established torrents and not starting a new one. As every user has there own CPU and Memory limits and bandwidth, really a lot of this is subjective to testing and finding out what works best for you. But I CAN tell you now that Micro Torrent users have (in general) poor download speeds due to bad settings or lack of knowlege, or both sigh.

I can however see how the client is so popular as it is really light on CPU and memory resources, and really easy to use but not advanced enough for my 'tweaking' needs hi... so I will continue to support Vuze (Azureus) for power users. But now I know this forum exists I will check in past from time to time so see what is new here.

Kind regards,

Rigmar Radio

Even with 15 upload slots on a torrent, you would gain little connecting to 50 peers at once...meaning not uploading to 35+ of those peers at any given moment. Those peers would likely get the impression you weren't uploading at all.

Such conditions may be semi-rare, but I'm sure it happens enough to explain some of the seeds-that-do-nothing that I've seen.

I may only be able to sustain uploads around 120 KB/sec, but usually anywhere between 2 and 6 peers can max my upload out. Whether it's on 1 torrent or 6 torrents hardly matters.

At some point seeding more torrents at once doesn't increase availability...only the illusion of such.

Two peers downloading 60kBs each would be fine, but how often do you see peers who have NO IDEA what the heck they are doing and running 25 torrents at the same time and taking only dial up speeds from you?

Too often I suspect. Fine on the slots, I normally just have enough to get the torrent out the door so to speak in as short a time as I can. After all when you are the only seed you are sort of tied up bandwidth wise and it is difficult to download anything for yourself when your upload bandwidth is all in use.

I use super seeding a lot, I see Micro Torrent calls that 'initial seeding' and in my opinion does a far better job of it than Azureus, an area the code team have sort of put on the back burner for a long time. Often when I super seed using Azureus, Micro Torrent users do not connect to me, which is there loss as I am the only one in the swarm, even if I do 'look like a peer' with 100% of the wanted goods.

This however is only true for about 10% of users.

I have not been able to find out why that is, but will do some more tests with Micro Torrent on my laptop using the Wi Fi and connect to 'my' swarm and see what I can find and report back here. Oh by the way I work as an Electronics Technical Officer deep sea with the BP Oil and Gas Tanker fleet and look after all the fly by wire and IT stuff on board as well as the navigation, radio and other 'toys' so when on 3 months shore leave have more time than most to devote to 'playing' on-line.

"but how often do you see peers who have NO IDEA what the heck they are doing and running 25 torrents at the same time and taking only dial up speeds from you?"

You can't really tell whether they have their upload speed set low, running too many torrents at once, have too many upload slots per torrent, a VERY bad ISP, or combinations of that.

A very common misconception is lowering upload speed very low increases download speed.

So people have upload speed set to 1 KB/sec GLOBAL while downloading...and unlimited (or yet again some low value) while seeding.

Even for much of my speed guide (2nd link in signature), the average upload speed per upload slot if max torrents are going at once is only about 2 KB/sec. We can do better, and should! uTorrent will reduce max upload slots per torrent if you have lots of torrents going at once if your global upload speed is high enough...so that if lots of torrents are active at once they may only get 1-2 upload slots each. That only partially compensates for the problem of low download speeds per peer/seed using my guide.

Many people want to run as many torrents as possible, and even if it's less than ideal (even by far!) better to give settings that can work with that in mind than more restrictive settings that won't get used...and encourage them to use "YouTube speedup settings" instead.

Ideally, uTorrent should run ...but not necessarily run well...with only 5 connections.

It should run ok with 10 connections and run great with 30.

But currently this is only true on torrents with very good peers+seeds.

So let's make better seeds+peers!

Sorry. I have a MUCH BETTER IDEA. Just run ONE upload, NOTHING ELSE. Two downloads. NOTHING ELSE and to hell with trying to sqeeze your bandwidth to the point YOU HURT the SWARM you are PART OFF.

Micro Torrent users PLEASE NOTE. Or I WILL BAN YOU FROM MY TORRENTS. Thank you. Rigmar Radio

Here's what Azureus has to say about good settings:

http://www.azureuswiki.com/index.php/Good_settings

I would like to understand the observations made in this thread better:

Rigmar writes "If you run more than one download and more than one [upload?] at the same time then your speeds will be very poor".

You mean the speed experienced per torrent? That is, if I have 8Mb down then I can only expect to get 4Mb on each of 2 downloads? Sure. The problem with utorrent is that it will not start the n+1 download when n active downloads fail to exhaust the available bandwidth (for whatever reasons). Therefore, users may actually experience improved download speeds over all queued downloads when configuring a larger number of download slots. There exists a perverse incentive, in other terms, to configure a larger number of download slots than are optimal if download #1 does (or rather: could) actually arrive at full blast.

Do I understand this right? If so, this is the second criticism of a slot-based scheduling algorithm that is oblivious to the actual bandwidth uptake on the already active slots.

Switek writes: "Even with 15 upload slots on a torrent, you would gain little connecting to 50 peers at once...meaning not uploading to 35+ of those peers at any given moment. Those peers would likely get the impression you weren't uploading at all."

I loosely based my config on your guide for 512kb, Switek, and have configured my "Bandwidth" settings as max peers/torrent = 35, upload slots =4. I thought that utorrent was allocating these 4 slots on rotation to all the peers fairly, so that no-one ever gets the impression I am not uploading. Wrong? If so, would I not better - lest I create a false impression vis a vis my peers - lower considerably my max peers/torrent?

Thank you.

"I thought that utorrent was allocating these 4 slots on rotation to all the peers fairly, so that no-one ever gets the impression I am not uploading."

Some peer rotation does indeed occur with the upload slots, but it is somewhat lopsided in favor of peers that can download quickly. Ironically, those who are leeching with their max upload speed set very low have far less trouble downloading from a seed than one that's uploading too close to its max speed. Since the peers have no way to tit-for-tat "return the favor" the seed can only upload to the fastest ones and hope for the best.

Even if the 4 upload slots are on rotation to all the peers fairly and they spend an equal amount of time on each...and there's a minimum of 15 seconds spent on a peer at a time...then each upload slot has roughly 9 peers to satisfy. By the time the 9th peer is reached, at absolute minimum 135 seconds has passed...but quite likely more than double that amount of time has passed. The problem is automatic timeout for inactivity defaults to 300 seconds. (5 minutes) uTorrent can be kicking peers even before they get a chance to download once.

Assume 30 seconds is spent on each peer and you're uploading at 48 KB/sec split between 2 torrents with 35 peers each using 4 upload slots each. This means each upload slot is getting 6 KB/sec on average. 30 seconds of that is 180 KB. Even if the piece size is 256 KB, the peer has to wait through 2 "rounds" of upload rotation through the peers to finish 1 new piece from the seed. This would take roughly ~260 seconds (4.3 mins) given perfect conditions with these assumptions before a peer gets a new piece to share with the rest of the swarm.

Larger torrents have piece sizes of 2 or 4 MB. The average time for a peer to get a completed piece from the seed is roughly 50 minutes for 2 MB piece size and 99.5 minutes for 4 MB piece size.

Only completed and checked pieces will get shared by the peers, so this often creates feast-or-famine conditions where peers alternate between downloading very quickly from one another (to share a new piece to them) to not downloading at all (or slowly downloading sometimes from the seed.) This is aggravated immensely if any of the peers are downloading the same piece/s from the seed as other peers, as the seed ends up uploading the same pieces multiple times. Which is why sequential downloaders can wreck a torrent swarm -- they'll all request their lowest missing piece first from the seed/s even if there's plenty of peers they could get that from.

Even with upload slots set to 4 and given the assumption that most of the peers aren't terribly bad, 10 total peers per torrent would be more than sufficient to keep the upload maxed out indefinitely. Were upload slots set to only 1, probably 5 total peers would be enough. The few connected peers would get completed pieces much faster and thus all be potential uploaders to others in the torrent swarm. The seed could even quit making outgoing connections once it reaches connection max, saving even more bandwidth. It could probably even stop doing that once it reaches 7-9 connections so the remaining ones can be filled up by incoming (possibly firewalled?) peers. (As far as I know, uTorrent already stops attempting to make more connections if it has connection max on a torrent.)

The problem is...you cannot currently set your max connections per torrent to only 10 without it affecting ALL your active downloading torrents too! They could end up connecting to 10 seeds, thus leaving you nobody to share with...or 10 very slow peers or seeds which give you little no matter how much you give them.

First of, thank you very much for the long-hand reply. I appreciate the effort you made and it makes it considerably easier to follow you.

"Some peer rotation does indeed occur with the upload slots, but it is somewhat lopsided in favor of peers that can download quickly."

That bit I can understand, and even makes sense to me on reflection. Fast downloaders are simply more insatiably. That need not be a bad thing if we assume that folks who have the physical capacity to download fast also have a higher upload capacity. These fast leechers could in turn provide bandwidth to the swarm more effectively than the seed can itself and the swarm would in fact do better if the seed discrimminated against slow leechers - which, I guess, is Rigmar's argument. In fact, I now understand that Rigmar's extreme reaction - block slow leechers - even helps slow leechers themselves: instead of getting little attention from Rigmar (where they are being crowded out by faster leechers), blocking them outright would make them turn away to other peers where they will likely meet a slower crowd and thus become less discrimminated against. In other words, a policy (by the seeding utorrent) of ranking downloading peers by their download speeds and terminating/snubbing those that would make the seed exceed the available bandwidth (*) would lead a utorrent swarm to restructure itself (as snubbed peers look for new seeds) such that the speeds of interacting peers would align themselves more closely and thus improve the efficiency of the swarm overall.

(*) As I set out in http://forum.utorrent.com/viewtopic.php?pid=408555#p408555, I think that, for uploading, it would make more sense to configure maxTorrentBW than maxTorrent#.

"With upload slots set to 4 and given the assumption that most of the peers aren't terribly bad, 10 total peers per torrent would be more than sufficient to keep the upload maxed out indefinitely"

I can empirically confirm this to be a correct (as long as, owing to a crafty ISP in my case, the seeding torrents rotate once in a while). I will continuously max out with only 6 peers.

The problem is...you cannot currently set your max connections per torrent to only 10 without it affecting ALL your active downloading torrents too! They could end up connecting to 10 seeds, thus leaving you nobody to share with...or 10 very slow peers or seeds which give you little no matter how much you give them.

I want to reply to this in http://forum.utorrent.com/viewtopic.php?pid=408555#p408555. These two threads are becoming quite related, also as regards downloading. Allow me to import a quote from there which I feel is better addressed in this thread:

Any policy that continues to start new torrents until max download speed is reached is a quick disaster. Upload speed is too much of a limiting factor, so anyone downloading much faster than they're uploading for hours or days straight becomes increasingly unlikely to return the favor to others. This serves only to prematurely kill torrent swarms.

This seems in direct contradiction to Rigmar's contention, which I now follow and share. I believe that I can see the assumptions on which your statement is based, and I think it would be valuable to validate those one by one:

(i) Most folks are on asymmetric connections and can download faster than they can upload, even if willing.

True - though it does not matter so long as folks are willing to seed long after.

(ii) Folks (therefore) download more than they upload.

Can this really be said of the community? My box serves up bandwidth 24/7. I download ca 1 torrent/week - 2 perhaps. After all, I don't download indiscrimminately. I need to think first what I want. Uploading on the other hand does not require any thoughts on my part. It just happens... Not true, I'd say.

(iii) Folks don't seed after they've leeched.

A popular accusation. But does it stand up to scrutiny? There are public torrents out there with 18,000 seeds. This makes me think that it is not an unwillingness to seed but rather a deficient seeding strategy that's at fault. Certainly, if I left utorrent to do its thing, it will only seed my highest-seeded torrents. And I will look like a leech on all other material. Not true, I'd say.

I will make one qualifying observation re (iii): I came back to p2p technology via Opera's inbuilt torrent client after my first, frankly disastruous, encounter with BBC's iPlayer. I mention those two clients because they are both deficient in different ways:

BBC iPlayer had the p2p community (private though it is) at its heart in so much as it clandestinely installed a service on my machine that would eat all available CPU, TCP connections, network bandwidth and disk space 24/7 in the interest of the Beep. I never managed to get anything downloaded but I am sure that the community had a ball at my expense.

Opera, by contrast, is a brilliant leecher and a total disaster for the community. It will only upload so long as the browser is running. And it will wreck your network connectivity whilst doing it, so even the dimmest user will learn pretty quickly to stop any uploads.

Somewhere between these two extremes should you aim to position utorrent (as it comes out of the box).

(1) I run Win XP (for my sins) and I actually need to login and manually start utorrent to serve the community. Naturally, I have moved utorrent into my startup folder so that it now launches automatically when I logon - but I had to configure this - utorrent's installation did not do this for me.

(2) My box is a shared family PC. The "right" thing to do would be to offer every one of my (limited) family users the utorrent front-end so that they can instigate downloads as they like. However, the admin account should be in charge of a utorrent service that starts automatically, runs all the time and implements the seeding strategy.

If utorrent came like this out of the box, then you would likely find that your user base becomes more community-spirited. And such a community would surely be better served by simply activating queued downloads until the available bandwidth is clobbered, no? Since this would help to address Rigmar's original grievance...

Some if not many fast leechers can download quickly because their upload is not heavily loaded...implying they may not be uploading much at all even though they are able. These (some/many) are almost the LAST peers I'd want to be uploading to as a seed. But I do want to upload to them if I have any spare upload left. Since I cannot directly know whether they're uploading to other peers or not, a policy to seek them out and punish them is likely to do more harm than good. Initial seeding indirectly ferrets them out, but has its own problems (underutilizing upload and masks seeds as peers) that it's not a good all-around solution.

One of my lesser proposals was to have seeds "remember" who rewarded them well while they were still downloading, and send proportionally more of their upload to them to insure they become seeds too...sort of an after-the-fact tit-for-tat.

I have banned the only seed on a torrent I was downloading that was constantly uploading to me at <1 KB/sec. Because there was less than 10 peers on the torrent, I figured I made everyone else a little faster downloading from that lone seed. In short, they completed pieces quicker and I got those pieces from them quicker. I was already keeping my upload maxed out between that torrent and 1 or 2 others.

In another post by me, I said that trying to structure a torrent swarm by speed of peers/seeds doesn't work. How would a symmetrical fast line fit in? Or highly asymmetrical? Should we only consider a peer or seed's max upload and just try to match peers/seeds based on that?

The example given was someone with 8 megabit/sec download and 0.5 megabit/sec upload that wanted automated queueing to keep that maxed out. (Done so by starting more torrents/connections when not maxed out.) Unless they quit acquiring torrents for a long time, they can never seed back 1:1 all they get. The longer they keep their download maxed out, the FAR longer it would take to seed back to 1:1 and thus they become increasingly unlikely and eventually unable to do so.

With a big difference in download and upload speed max, a high download speed consumes a large percentage of the upload speed even while uploading nothing to other peers. Downloading 800 KB/sec would consume at least 20 KB/sec upload, roughly 40% of all that's available...leaving maybe 30 KB/sec upload for others. This has created the unfortunately common belief that it is "best" to set upload speed very low while downloading.

As a general feature/behavior of a torrent client, this (automated queueing to keep download maxed out) would indeed be a disaster -- creating far more (possibly unwitting) hit-and-runners than there already are. These would easily kill torrent swarms.

Overall, there is more uploaded than downloaded. Due to inefficiencies and bugs of various BitTorrent clients, this difference could even be >10% more.

On public torrents, much of the uploading is done by only a small fraction of users. This is due in large part to very few having very fast uploads, so those that do support those that don't. BitTorrent isn't about guaranteeing great download speeds, only that everyone can complete the download...its methods are just generally good for decent download speeds.

On private torrents, many people run FAR FAR too many torrents (to be active at once) for their upload speed so if/when any torrent is downloaded...some of it will be downloaded from them.

Almost everyone seeds "a while" after completing a torrent download, because it is hard to manually stop a torrent the moment it finishes downloading. (Opera and other leeching clients are an exception to this rule, but let's just not consider them the norm for now.) But for many, that "a while" is less than 5 hours. Quite likely, a large portion of BitTorrent users don't run their computers for more than 8 hours a day...and may have a torrent client running only 1-7 hours of that. Worse, they may be doing that all during peak evening hours...not making any friends with their ISPs when they do. They probably have day jobs/school and can't stand (or not allowed) to leave their computers on while they sleep.

Anywhere between 40-80% of everyone using a torrent client is firewalled in that client. This is because of the common use of routers now, ADSL modems that have internal firewalls and mini-routers of their own, wireless and satellite connections that are hopelessly firewalled, and software firewalls even hidden inside antivirus/antispyware products. This probably causes more poor torrent swarms than hit-and-runners/leechers, bad ISPs, or people using bad settings. NAT hole-punching by Teredo and uTP will go a long ways to relieve some of that...but as of right now they make up only a very tiny minority of connections.

"There are public torrents out there with 18,000 seeds."

Often that's an example of miscounting or at least a useless statistic. Many of those seeds may have just quit, be firewalled, have hopeless settings, or be on a bad ISP that makes downloading from them hard to impossible. With a private torrent only a very tiny fraction of those (maybe 1-50) would be available per tracker update (about once per hour.)

"if I left utorrent to do its thing, it will only seed my highest-seeded torrents."

These advanced settings hopefully reduce that:

queue.prio_no_seeds

queue.use_seed_peer_ratio

Also, the queueing option of "Seeding tasks have higher priority than downloading tasks" should help as well.

So too should the default ratio of 150%, once a torrent reaches that ratio it is less likely to be chosen for active uploading if many are queued.

I need no more examples of bad clients or bad client settings to estimate they are probably major contributors for torrent swarm problems.

There's a checkbox in uTorrent's settings to always run on startup. The reason that's not the default setting is if (due to bad drivers) uTorrent caused computer lockups...the average user would be hard-pressed to work around that. They have to be able to successfully run uTorrent once to have it run on startup. I've also heard uTorrent may load before some software firewalls load...proof of severe security issues/bugs in windows in general!

Splitting a limited consumer connection between multiple torrent clients generally means they all run with bad settings.

It would be nice if uTorrent came with good settings "out of the box", but sadly uTorrent is generally unable to make educated guesses about the capabilities of the connection so it can self-configure itself.

Without good settings, "activating queued downloads until the available bandwidth is clobbered" is very short-sighted.

BitTorrent lives, breathes, and DIES by how well it can upload.

Thanks again, Switek.

"There's a checkbox in uTorrent's settings to always run on startup."

I hadn't actually seen that! Checked now...

"These advanced settings hopefully reduce that:

queue.prio_no_seeds

queue.use_seed_peer_ratio"

Yep, they are all set - by default even.

"Also, the queueing option of "Seeding tasks have higher priority than downloading tasks" should help as well."

Haven't done this because I download so little that it doesn't really matter.

"So too should the default ratio of 150%, once a torrent reaches that ratio it is less likely to be chosen for active uploading if many are queued."

This doesn't work for me at all. Although I download little, I always try to download from the strongest swarms for any given material. That means that I still have torrents that are miles away from uploading to 100%. These swarms are so strong that no-one's really taking a lot from me. Yet these torrents pre-empt the rarer material from seeding which has long acquired ratios > 300%.

I have therefore set my ratio=(-1) and am now seeding purely on seed:peer ratio. Ironically, other strong swarms continue to give me headaches. One that my utorrent always wants to seed has supposedly 1055 seeds and 2816 peers, ie an awful seed:peer ratio of just 0.374. I think that the Vuze guys had the right idea when they allow the user to configure "consider x many peers equal 1 seed": 2800 peers should really be able to entertain each other, no need for me to get involved.

With 1.8.2, once a torrent actively seeds, it will not stop for as long as peers are active on the torrent. And with large swarms, there always comes someone knocking on my door. So it is only by manually stopping these large swarms that I can stop them from monopolizing my upload slots.

Finally, could I just ask you to educate me as to the basis of this calculation:

"Downloading 800 KB/sec would consume at least 20 KB/sec upload"

And what happens if the 20KB/sec cannot be made available (for whatever reason) - does this throttle the download speed? Why?

PS: I am glad to notice your very realistic assessment of the practical constraints most users face. It took me an inordinate amount of time to sort out myriad issues with the p2p stuff - and as these lines prove, I don't think I am done yet :/

"I hadn't actually seen that! Checked now..."

There's stuff in the FAQ and documentation that even I don't know or have forgotten.

"These swarms are so strong that no-one's really taking a lot from me."

Then there's no need for you to upload on them (unless required/forced by the tracker.) Stop them and seed other torrents instead. Your upload bandwidth is limited, use it wisely!

"One that my utorrent always wants to seed has supposedly 1055 seeds and 2816 peers, ie an awful seed:peer ratio of just 0.374."

That torrent likewise isn't dying anytime soon. Stop it and check back on it in a week or 2.

Having uTorrent decide everything for you seems a little strange to me, especially now with RSS where it can even (in a sense) choose what to download!

"Downloading 800 KB/sec would consume at least 20 KB/sec upload"

TCP/IP networking limitation of TCP connections. SYN-ACK packets. If the uploader doesn't get the ACK(nowledgment) packet in a timely manner, it is supposed to slow down or stop its upload rate...because presumably the line is being bottlenecked somewhere and packets are probably getting lost. The 40:1 download-to-ACK ratio is just a side-effect of a full download packet size versus tiny ACK reply packet. Other overheads (BitTorrent overhead, lots of connections at once, high half open limit) can make the ratio possibly as bad as 10:1.

Teredo, IPv6, and uTP packets won't have this problem to the same degree because they're all UDP based and are NOT required by the protocol to have 1 ACK packet for every packet they send. However this means they're less stable/reliable. A reply system had to be designed for each of them that's not entirely different than TCP's SYN-ACK system so even they cost some upload for fast download speeds -- but it's probably/hopefully more like 100:1 download/reply upload ratio.

"It took me an inordinate amount of time to sort out myriad issues with the p2p stuff"

There's only a handful of rude shocks left. Increasing numbers of hostile "ISPs" (at some point it's not fair to say they're really providing internet access), copyright monitoring corporations, torrent poisoners, virtual ineffectiveness of Peer Guardian 2 (or any ip blocklists) to deal with those problems, ISP limitations, ...or BitTorrent users trying to use "YouTube uTorrent speedup settings". Hopefully you're familiar with all that already.

"Having uTorrent decide everything for you seems a little strange to me."

Really? The thing is, every one of my users knows what they want to download and that they want it NOW. Yet no-one here spares a thought for the uploading aspect. That's why I (admin for our box) want to implement a strategy that ensures that my users behave like good p2p citizens. But I don't want to spend time on this. I just want utorrent to get on with it. Hence why I am not impressed with having to do the stop-start bit myself. If I can do it, just by taking a glance at the queue, then so should the s/w be able to do it - and better...

"There's only a handful of rude shocks left."

Can't say I have come across all of them, but I have yet to see an instance where peer guardian would actually have blocked someone at my end...

Thanks for all your help!