A different upload approach

[Neighbor]

Hi ppl! I just recently discovered µtorrent and i must say i like it so far. I was using Azureus since it was the only fair player that also had all the features i needed. But it shares one questionable setting with all other bittorrent apps i know: upload slots per torrent.

But what is the actual reason behind this setting? It's how fast you upload to each individual peer, isn't it?

So it would be more intuitive with help of this setting instead: minimum upload per peer.

Now how would it work out:

Let's say you want to achieve an upload of 3kB per second per peer. So you configure that option accordingly and the program will do the math for you: it will open up as many upload slots per torrent as long as it kan keep up an upload speed of at least 3kBps per user. That way the user has one less setting to deal with.

If the result is an uneven number it will evenly increase the upload for all active slots until the overall maximum upload is met.

So, what do you think? IMO this more reasonable than the current way and would make µtorrent stand out of the crowd some more.

Cheers

Dan

[ScubaSteve]

upload slots per torrent means how many ppl you want downloading off u per torrent, i have mine set to 2 currently but with the option use additional upload slots if upload speed < 90% that way i will be giving fairly good speeds to other peers instead of having 5 different ppl downlading at 5kB/s i have two at about 14kB/s

[Switeck]

I do think uTorrent should enforce an ABSOLUTE limit on the max number of uploads allowed at once, based on the CURRENT max upload bandwidth.

If you limit upload bandwidth to 4 KB/sec, you shouldn't be allowed to set max uploads at once to more than 8 -- which would be giving out an average of 0.5 KB/sec to each (actually less than that due to overheads.)

This is ESPECIALLY important for seeders -- who have to upload a complete chunk of a file (which is typically 256KB, 512KB, 1MB, or 2MB in size) before the downloader has anything to share to others. At 0.5 KB/sec even the smallest standard chunksize of 256 KB will take over 8 1/2 minutes before even 1 full chunk is available to be shared by that downloader.

It is potentially an exploitable feature of uTorrent if someone wanted to cripple a tracker -- they could launch many, many instances of uTorrent (possibly needing multiple computers for each or at least special 'sandboxes' for each), set upload bandwidth max to 1 KB/sec and max uploads + max connections to in the 1,000's.

Everyone would get tied into their ips as they might have the numbers to dominate a tracker, making one of their bad ips a likely connection for any random joiner to the tracker. But because their upload bandwidth is throttled to only 1 KB/sec and they may have 100+ uploads allowed, the rate people get files from them would be basically NIL.

[Firon]

that's probably going to happen in the next version. right now, it won't let you set more than 10 upload slots regardless of the cap.

[dudeboyz]

It won't bog Utorrent down adding stuff like this, right?

[splintax]

This will add a few bytes at most, so no it won't bog down µT. It's only adding many new features that require significant amounts of code (eg. DHT, that introduced about 15KB IIRC) that increases the size of the program - and even that doesn't 'bog it down'.

I imagine that RSS, which a lot of people are looking forward to being implemented, would add about 10KB should ludde decide to include it.

[Firon]

DHT made it 6kB bigger, rss is making it about 4kB bigger (including the parser and related UI elements)

[dudeboyz]

why add rss?

[Animorc]

Because it has been requested several times.

[Klaus_1250]

that's probably going to happen in the next version. right now, it won't let you set more than 10 upload slots regardless of the cap.

I'm happy to hear this. I really don't appreciate people uploading to me at < 1KB/s. I personally wouldn't even mind if µTorrent would cut off such slow downloads. They not worth the overhead, and I'd rather have someone uploads 1KB/s to one person, than 0.1KB/s to ten. I'm not sure about the maths, but I can imagine the latter will reduce the overall torrentspeed in comparison to the first.

It might even be used as a p2p attack-strategy, sending out corrupted data at an extremely slow pace?

[splintax]

DHT made it 6kB bigger, rss is making it about 4kB bigger (including the parser and related UI elements)

Really? So RSS is definitely happening and under construction for the next version right now? Excellent!

Just realised I was a little confused about DHT.. I remember I only started using µT in place of Azureus when DHT was available. At that time I had a version of µT sitting on my flash drive that was only 85KB.. didn't use it much so it didn't automatically update. Then I updated to the new 105KB version so I assumed that was all due to DHT, but apparently there were a number of versions in between.

As far as RSS addition goes.. there have been a number of requests, just search the forums. And the main reason to add it is because many (especially tbsource-based) trackers provide RSS feeds that can be used to automatically download stuff, a process known as broadcatching..

[1c3d0g]

why add rss?

Indeed.

[Neighbor]

First up: thanks for your replies. I'm a little confused right now though.

that's probably going to happen in the next version. right now, it won't let you set more than 10 upload slots regardless of the cap.

Were you refering to me or to what Switck wrote?

Everyone seems to talk at cross purposes a little bit. So do you ppl like what i suggested or not?

Cheers

Dan

[boo]

why add rss?

Indeed.

probably because people want to keep track on new torrents

that gets added to their favorite BT sites.

Personally I would have some other program do the rss' date='

for example I use Miranda IM with the RSS plugin

EDIT: oh, the RSS function is going to do this:

[url']http://forum.utorrent.com/viewtopic.php?id=72

it reallt sounds like a bloated feature

[Firon]

First up: thanks for your replies. I'm a little confused right now though.

Were you refering to me or to what Switck wrote?

Everyone seems to talk at cross purposes a little bit. So do you ppl like what i suggested or not?

Cheers

Dan

I was talking to Switeck.

Your idea's good, though it's been asked for before (on IRC I think, not the forums). ludde seems to like the idea of mimimum kB/s per slots, so I think he's gonna enforce a 2 kB/s minimum per slot based on the upload cap. (not exactly what you asked for)

[Switeck]

ludde seems to like the idea of mimimum kB/s per slots, so I think he's gonna enforce a 2 kB/s minimum per slot based on the upload cap. (not exactly what you asked for)

I'm ok with it being 1 KB/sec per upload slot, based on the upload cap. That might keep the math and programming slightly easier too.

However, it also has to be applied across the max number of active torrents too. If someone has 10 active torrents with 4 upload slots each and sets their upload bandwidth cap to 20 KB/sec, that'd mean either not all 10 active torrents will have 4 uploads going at once...or many of the uploads will be even less than 0.5 KB/sec.

With max packetsize being 1500 bytes for internet connections and only about 1400 bytes of that can be payload (pieces of a downloaded/uploaded file), I'd imagine even 1 KB/sec might be jarring -- going from 1 packet-burp uploaded a second to 0 packets uploaded the next second.

[splintax]

IMO, the RSS features are analogous to the scheduler.

Unnecessary and not even really part of BitTorrent, but damn helpful for people who work/go to school/sleep and want to get the client to do stuff automatically for them. To the people saying RSS = bloat, do you consider the scheduler to be the same?

[1c3d0g]

Yes, I do. :| Then again, I can certainly understand people who need the scheduler due to the crappy way some ISP's charge bandwidth use... :/

[Switeck]

that's probably going to happen in the next version. right now, it won't let you set more than 10 upload slots regardless of the cap.

Do you mean 10 upload slots per torrent? I know I can put in a value over 10 and µTorrent won't reject that value...but I don't know if it uses it. I simply haven't bothered to test it.

However having more than 10 upload slots total across multiple active torrents as opposed to 10 upload slots on 1 torrent doesn't really make any difference if the upload bandwidth is 1 KB/sec total.

Either way, it breaks compatibility with the BitTorrent protocol.

[Firon]

10 upload slots in Torrent Options. you can set higher, but it ignores them. It DOES help to an extent, since stupid people won't be able to use ridiculous numbers like 100 slots on a 30k upload connection. 1.4 should act even better.

And what breaks compatibility?

[Switeck]

And what breaks compatibility?

If for instance a user sets µTorrent to 10 uploads per torrent, allows 2 downloading torrents, allows 4 total torrents (2 in seeding, 2 downloading), and has upload bandwidth max set to <20 KB/sec...they are breaking compatibility with the BitTorrent Protocol, specifically on these parts:

"It should cap the number of simultaneous uploads for good TCP performance." and "Reciprocation and number of uploads capping is managed by unchoking the four peers which have the best upload rate and are interested." (The second part is only loosely followed now by ALL major bittorrent clients.)

This means the upload bandwidth PER upload must be enough that you get "good TCP performance". The minimum value for that is somewhere between 0.5 KB/sec and 2 KB/sec PER upload slot. (Approximated based on number of uploads, round-robin upload cycle times, probable 1400-1500 byte packet size, typical 16 KB file piece requests, 30-60 second time window before other side will likely choke you, etc...)

With potentially 4 torrents at once, EACH with 10 uploads at once, that works out to be as many as 40 separate upload slots. To achieve a minimum of 0.5 KB/sec upload speed PER slot, they'd need to set their upload bandwidth to at least 20 KB/sec. Due to optimistic unchokes, they'd actually need even more.

An important consideration is whether µTorrent tries to maintain 'average' speeds of per upload slot by uploading constantly to each upload slot even when set really slow, or whether it tries to maintain average speed by round-robin uploading to them at closer to the max upload speed allowed. The second would generate tiny bandwidth spikes followed by nil for the receivers but would not leave their connection 'starved' waiting for the end of the current packet which may exceed the timeout delay.

[Nefarious]

i dont exactly care about the number of slots it uses, i have been seeding this torrent for a while which has 4MB pieces and i coiuldnt make utorrent to do good job for me seeding as it disconnects from the peers too fast, i ended up going to bittornado for seeding as it keeps the peers connected to me for a long time making it easy to distribute full pieces, i was being able to send 0.2% almost for hour when on bittornado i am able to send 2% per hour (oh yeah forgot to mention i have slow connection)

I think utorrent needs to pulish the job on uploading/seeding more than just minimum/maximum slots per torrent

[chaosblade]

Im not sure a minimum of bandwidth per slot is the best solution. People with lesser upload speeds would be hurt in the process i imagine ( < 192kbits rates).

[1c3d0g]

Indeed. 128kb/s here...

[Klaus_1250]

Im not sure a minimum of bandwidth per slot is the best solution. People with lesser upload speeds would be hurt in the process i imagine ( < 192kbits rates).

But they hurt other people too. Most of my Wasted bandwidth is from slow uploaders. Uploading under anything than 1KB/s is pure waste of bandwidth. Personally, I would like to see an implementation of a minimal downloadspeed. If anyone uploads to me at less than 1KB/s, I don't want to waste a connection slot on it. And I don't need the data either, chances are it will end up getting wasted anyway.

This may sound a little harsh, it is not intended. But some people with slow connections really abuse them, downloading/uploading way more many torrents than their connection can handle. Slow uploads are also populair among leechers. And last, ordinary users don't always understand the implecations of slow uploading. Enforcing minimal uploadsspeeds (or downloadspeeds) is not to hurt people with slow connections, it is to make sure swarms stay fast and efficient. If swarms stay fast and efficient, everyone benefits.

BTW. 128kbs still gives you an usuable upload-capacity of 8 - 12KB/s, which is enough for 1 or 2 torrents with 4 uploadslots. I really can't see any excuse to upload below 1KB/s and such behaviour is known to have bogged down other p2p networks before.