Per-Torrent Policing - A Bad Idea

[Switeck]

If you really want faster download on that superhuge torrent, then set upload speed to 4 KB/sec, 1 upload slot, and LOW priority. Chances are, due to how slow uTorrent is about choosing the optimistic unchoke upload slot, most of the time that torrent will be uploading to NOBODY. Even when it is uploading, it will often be uploading for less than 4 KB/sec.

Or would you rather just be allowed to completely leech on one torrent...so long as you're uploading on "something" else?

[hermanm]

Switeck, I'm under the impression he wants the latter since even sharing 10% of upload bandwidth on a high seeds/peers is not something he wants to do. So, here's the question then...

How effective is using seeds/peers ratio to prioritize uploading assuming global upload amounts exceed the minimum upload rate? For example, a torrent with 1 seed and 100 peers (ratio 0.01) receives higher upload priority than a seed with 200 seeds and 100 peers (ratio 2.0). Can these seeds and peers number be presented falsely?

[jewelisheaven]

If by "false" you mean inaccurate, sure. All the time. Depending on the tracker the stats for scrape may be 12 hours old or more. Peerlists I think have a shorter timeout but that is still tracker-dependent.

Making mountains out of molehills (or fighting windmills) is something I don't disagree with, but you sure as hell better be prepared to logically present an argument and adapt the argument when you know you're getting nowhere. The feature will not be removed. I mean, c'mon that's the stance we got in the several iterations of this (lack of an) argument.

I still don't see where the problem is, TBH. If one runs alot of volume you increase active torrents and decrease upload slots. If one runs alot of volume seeding you prioritize seeds not downloads. If one runs alot of volume with dead torrents where you're the only seeder it takes some more finagling but definitely prio_no_seeds helps especially when you're the only (masked) seed in initial-seeding mode as 0 seeds always take priority over anything else.

[Switeck]

We cannot expect uTorrent to automatically guess what we want -- whether it be extremely high priority for poorly-seeded torrents, or to "hurry up" the download of an unfinished torrent.

[hermanm]

There seems to be an older related thread that does a good job of explaining queuing and active seeds.

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

[TheDude]

We cannot expect uTorrent to automatically guess what we want -- whether it be extremely high priority for poorly-seeded torrents, or to "hurry up" the download of an unfinished torrent.

Finally someone understands !

That is why uTorrent should leave it up to the individual user, rather than imposing some scheme that doesn't apply in all situations.

[jewelisheaven]

No.

[Switeck]

Your opinion is that IF you're sharing on one torrent, then you shouldn't be penalized with slower download speeds on other torrents that you have lowered upload speed to near-nothing.

(Near-nothing defined as: 1 KB/sec upload speed with 1 upload slot and low priority, with other torrents set to high priority and multiple upload slots.)

That per-torrent limit was added precisely because it was too easy to cheat the previous global upload speed limits:

1.Set global upload speed to 6 KB/sec

2.Set individual torrent speed to 1 KB/sec

3.Leech away at "full" download speed!

...This sounds a terribly lot like what you're asking for.

Sharing PER-TORRENT is required by the BitTorrent protocol.

That won't and shouldn't change.

[TheDude]

That per-torrent limit was added precisely because it was too easy to cheat the previous global upload speed limits:

1.Set global upload speed to 6 KB/sec

2.Set individual torrent speed to 1 KB/sec

3.Leech away at "full" download speed!

Except that all the cheater needs to do is to wait until there are no more leechers other than he.

At that point, you can set you per-torrent upload to 100000 kbps and it will still upload zero, while giving you full download speed.

So, once again, these measures don't accomplish anything.

- Cheaters always find a way around everything (cf "Slysoft")

- Sharers will stick with 1.7.7 (many still use 1.6.0)

- A few oblivious and light users will upgrade to 1.8.0

It might be somewhat defensible if utorrent 1.8 actually removed cheating, but all it does it make it more difficult for some of us who want to share on torrents with few seeds.

[jewelisheaven]

No.

[Switeck]

We are not so concerned with an aggressive few manually going to considerable lengths to leech on 1 torrent.

We ARE concerned about uTorrent being automated enough to do the same for them!

It's just like file priority inside a torrent or sequential download. As bad as being able to manually download 1 file at a time inside a multi-file torrent...it'd be FAR worse if uTorrent would do that automatically, sequentially downloading all the files in a torrent. It's one of the most shot-down requests for uTorrent.

Your idea is not quite that sinister, but the problems I mentioned with automatic leeching remains.

If getting back up to 12 times what you're giving on a torrent is not enough when you're not giving a lot back, then you may need to seek other means of downloading files.

Private trackers have their own self-inflicted disasters, I've mentioned a couple in this thread...as have you...that simply CANNOT be fixed because private trackers really strain the BitTorrent protocol as they're almost at cross-purpose to it. If it's a ratio issue, the tracker/webpage needs to reconsider its policy. Forcing 100's if not 1000's of ips to remain connected as seeds for torrents typically nobody is downloading at any given time is NOT a good idea!

[hermanm]

> Your idea is not quite that sinister

Seed on private tracker, and download fast on a public tracker. Its already bad enough on public trackers, where ratio obsessed users will upload bandwidth to private trackers before public trackers. You have to force upload, even a small amount, per torrent otherwise there will be more abuse.

[TheDude]

We are not so concerned with an aggressive few manually going to considerable lengths to leech on 1 torrent.

We ARE concerned about uTorrent being automated enough to do the same for them!

[...]

Your idea is not quite that sinister, but the problems I mentioned with automatic leeching remains.

Many of you talk as if I am proposing a change.

I am proposing that utorrent - with regards to download limits - stay as it is now (version 1.7.7) and has always been.

You act as if things have been horrible for years, and this change will fix things.

The reality is that most of the upload on torrents comes from high bandwidth users. High bandwidth users will not be affected by this change. Your minimum upload for unlimited downloading is a tiny fraction for a high bandwidth user, and so it doesn't affect them. They have never bothered to limit their upload on anything, because they have lots of it.

It is the low bandwidth user, the guy with only one or two really lame ISPs in his area (or only dialup!) who is hurt most by this change.

But they don't provide any significant portion of the overall upload on torrents, so the change only hurts them, but won't help torrents.

[jewelisheaven]

... http://utorrent.com/faq.php#What_does_Download_Limited_in_the_status_bar_mean.3F

To give you some history, here are some release dates for you:

--- 2006-01-06: Version 1.3.2-beta (build 391)

- Change: Show a message in the status bar if download is limited due to small upload

--- 2006-01-08: Version 1.3.2-beta (build 395)

- Change: Increase limited dl rate to 3x

--- 2006-01-16: Version 1.4.1-beta (build 405)

--- 2007-11-13: Version 1.8 alpha (build 6104)

Note that 05/09/19 -> 06/01/16 is 119 days, during which time uT went from pre-release stage to the 1.4.1 build mentioned in the FAQ. It had been a total of 666 days (06/01/08 -> 07/11/13) since then when the first public release of 1.8 came out (17 weeks, and 95 weeks 1 day). You cannot make up your mind. You are twisting words... and being quite illogical about it. (ex: if a low bandwidth dialup user must set their bandwidth low, the change does not affect them as they were likely already using a global upload limit to keep their bandwidth from choking their HIGHLY IMPACTED line. Bait and switch will not work here)

Additionally the first response to this was 6 weeks (42 days)after release, after a respected and level-headed member pointed out the limiting and wanted clarification. It wasin-fact a lovely Christmas present http://forum.utorrent.com/viewtopic.php?pid=292367#p292367

I say again, adapt your argument and use something other than "but I want it this way" or stifle.

[Switeck]

"You act as if things have been horrible for years, and this change will fix things."

The change was made in the first place to be closer in compliance with the BitTorrent protocol, both in practice and in spirit.

"Your minimum upload for unlimited downloading is a tiny fraction for a high bandwidth user, and so it doesn't affect them. They have never bothered to limit their upload on anything, because they have lots of it."

I don't know anyone personally who has so much upload that they don't need to limit upload speeds to prevent their connection getting laggy. Even 10 megabits/sec upload could get completely eaten by a trio of not-too-exceptional broadband connections in the USA...and they'd only be able to upload maybe 1.5 megabits/sec total back in return. (and I'm being generous to say they have that much upload!)

I've seen numerous examples of people lowering their upload to ridiculous levels compared to the speed of their line simply because they believe it makes their downloads faster. Having a fast line doesn't automatically make one generous...or smart.

hermanm corrected me...maybe it is more sinister.