Changes in upload slots management in new betas?

[kurahashi]

I've noticed, that something has really changed but haven't found anything about it in changelog.

I don't know exact what algorithm is implemented now, but I am seeing much less upload slots opened (or used) than before, regardless of my preferences setup. For example, I have two torrents active with 3 upl slots per torrent set, and I'm often seeing only one per torrent being used. Interesting...

[Firon]

Yes. It was changed. Turn on the debug column and see the last value to see how many "allowed" upload slots it has for that torrent.

[kurahashi]

Turn on debug column?... how? You mean logger?

[µtorrent-Guest]

right click in the colums line "downspeed, upspeed,IP,inactive,client and so forth" you can choose many more columns to display (19 to be exact)

[kurahashi]

wow. Didn't know about it

BTW, right now this number is -1, what does it mean?

[µtorrent-Guest]

No knowledge, just guess;

-1 = default

[Switeck]

I must say I like this change.

If I accidentally allow too many upload slots at once, it is cutting the numbers back to something at least semi-reasonable.

I did a 10 minute torture test to see it in action. Seeding 9 torrents, 20 upload slots each, with upload speed only 42 KB/sec. It's still uploading at ~0.4 KB/sec per upload slot, far better than the <0.1 KB/sec it would be without the new change!

After the test, I stopped most of the torrents and reduced upload slots to only 3. I left seeding the ones with few seeds and very low seed-to-peer ratio ones.

[kurahashi]

I did a 10 minute torture test to see it in action. Seeding 9 torrents, 20 upload slots each, with upload speed only 42 KB/sec. It's still uploading at ~0.4 KB/sec per upload slot, far better than the <0.1 KB/sec it would be without the new change!

Tsk. But why reduce their number to achieve ~0.4kB/s only? Why not ~1kB/s... or ~2kB/s, or even ~5kB/s? This should be setable by user, because in this way... in this way we would have global upload slots implemented. Well, more or less and in a roundabout way but still

So, generally move done in the right direction, but this feature still needs improvement I think.

[Firon]

It's always limited it, it just never told. But it's a bit more aggressive now in limiting the slots based on active torrents + upload caps.

[Switeck]

Yes, it's always limited it. However the limits it allowed were really lax in the past -- as I've seen <0.1 KB/sec upload speeds per slot before.

"But why reduce their number to achieve ~0.4kB/s only? Why not ~1kB/s... or ~2kB/s, or even ~5kB/s? This should be setable by user"

I wasn't trying to find 'best results'. I was running the settings to torture-test almost worst-case-scenarios. I had NO intentions of running with such awful values for very long.

This is AUTOMATIC enforcement which is reducing upload slots. And this should ONLY kick in when the user tries insane values (like I did for my torture test). That is why it's ~0.4 KB/sec instead of 'even ~5 KB/sec'.

I've already put in my vote FOR user-setable upload slot speeds instead of having to micromanage it every time I change the number of torrents I'm running or change upload speed. Gotta love when Scheduler kicks in and suddenly upload speed per slot starts sucking. Or with 2 active torrents, you lower priority on 1 and raise it on another...the low priority one still has the same number of upload slots but is now uploading at terrible speeds per slot!

The BitTorrent protocol spec mentions maintaining good TCP behavior, and this includes a minimum speed per upload slot (much greater than 0.1 KB/sec) even though this isn't spelled out exactly. This is similar to not hammering trackers with requests and not allowing people to set their upload speeds to 0 KB/sec. (...or even limiting download speed to only 6x upload speed if uploading <6 KB/sec IMO) Exceeding these limits is breaking compatibility with the protocol. Or you can just call it cheating, even if it's not a beneficial cheating!