seeding and slow_ul_threshold

[ovonrein]

Hi,

I am (relatively) new to the bit torrent community and I would like to understand how to configure my utorrent such that it most effectively supports the community.

I learnt the other day (on this forum) that a utorrent client decides on an entirely discretionary basis which torrents to take out of "queued seed" into "active seeding". The scheduler makes this determination based on (1) distance to the target ratio; (2) seed count (if queue.prio_no_seeds=true); and (3) seed/peer ratio (if queue.use_seed_peer_ratio=true).

The net effect of the default configuration of my client was that out of a large number of torrents in my queue, only about 4 would ever actively be seeding at any one time. That seemed understandable since I had configured, in accordance with the bandwidth formula, only a max of 4 active connections.

I was concerned, however, with the selection that utorrent made. I have a couple of very old torrents with very few seeds (ie very rare material) that had long hit their target ratio (since they had been hit previously, for lack of seeds, disproportionately heavily). These torrents were simply no longer scheduled at all since, no matter how few seeds there are out there, once a torrent hits its target, utorrent will not schedule it again until ALL OTHER torrents have also reached their target.

This let me to lower my target from 250% - hard to achieve on very heavily seeded, recent material - down to 100%. But that did not change seeding behaviour appreciably. So I decided to set the target ratio equal to (-1), ie no target at all. This rocked the boat some...

The number of torrents now actively seeding actually exceeded the number of configured connections(!) - though not all of those torrents were actually pumping data. Rather puzzled, I looked at my configuration and noticed a parameter queue.slow_ul_threshold which is set to 1,000 bytes/sec by default. Any torrents uploading slower than this (which includes those that are simply waiting) do not count towards the total of my max configured connections, the manual says.

Aha!

Curious thing was, though, that all the while this was going on, the active torrents did not always make full use of the available upload bandwidth.

First question/observation/suggestion:

Should the utorrent scheduler not simply continue seeding torrents for as long as the available upload bandwidth is not fully utilized? Should such dynamic considerations not override static configurations like max connections and slow_ul/dl_threshold?

Well, that's not how it's done in 1.8.2 so I figured the best static approximation I could think of was to set slow_ul_threshold=max_upload_rate/max_conncetions.

Now utorrent rocks. All torrents are actively seeding, there's data action on all of them and my upload bandwidth is totally exhausted. However, and perhaps unsurprisingly, the data throughput per torrent has dropped from 12Kb/sec to 1KB/sec or less. That is, I am not producing torrents but trickles...

Second question:

What serves the BT community better: A handful of torrents - on a rotating basis - pumping out reasonably high data rates or a large number of seeds steadly ploughing away at lower rates? (And if it is the former, will utorrent assure, given a target ratio of (-1), that lowly seeded material will get scheduled on a regular basis?)

Thank you.

[DreadWingKnight]

What serves the BT community better: A handful of torrents - on a rotating basis - pumping out reasonably high data rates or a large number of seeds steadly ploughing away at lower rates?

Small numbers of torrents on a rotation. If you can't get even single request blocks out in a timely manner, you're not using your bandwidth in an efficient manner.

[ovonrein]

But I observed that when on rotation over a small number of actively seeding torrents, utorrent did not appear to use all of my available bandwidth (which might be down to some bottleneck on the receiving end, correct?).

By writing "If you can't get even single request blocks out in a timely manner", you mean I should ensure that I should strive to pump out individual pieces in ... what sort of timeframe?

As I wrote before, I am primarily concerned with the fate of a few torrents which are not well seeded on public trackers. If I lower again slow_ul_threshold - which is I think what you are suggesting - to reduce the number of active seeds and leave use_seed_peer_ratio=true and target ratio equal to (-1), would the resulting rotation in the seeding queue give higher priority to the less well seeded torrents?

I am intrigued in how the bit torrent protocol strives to resurrect moribund torrents. If a peer comes along and wants to download a torrent to which I am the only seed but my seed is currently out of rotation, how are we going to meet. You answered once before "by appointment". How does that work?

---.---

I just lowered slow_ul_threshold to a point where torrents would drop back into "queued seed". It was quite interesting to watch utorrent. The first torrent it decided to knock back into the queue was the most actively pumping torrent. In so doing, utorrent freed up a lot of bandwidth but this slack was not taken up by other active pipes - they simply continued to trickle. As I write this, utorrent utilizes only half the available bandwidth.

---.---

Bandwidth is back up to capacity, so it probably took utorrent some time to implement the new strategy...

[Switeck]

BT Central ADSL ISP in the UK throttles BitTorrent traffic HEAVILY during peak evening hours.

This too can cause problems in uTorrent...

[ovonrein]

Thanks, Switeck, that's me. Any pointers on how to defeat that devil ;-> ??

I also notice that, this morning, all but 4 torrents have reverted to "queued seed". I honestly do not understand how this can be good for the BT community. To my simple mind, utorrent should advertise (as ready to seed) everything it's got all the time. I could then configure a min_ul_threshold, say, such that if there was spare bandwidth > min_ul_threahold any incoming request for pieces on a (seeding but) inactive torrent could be serviced immediately (*). If bandwidth were totally exhausted (which it really ought to be all the time), then utorrent could simply look at the seed:peer ratio for the requested torrent and compare it to the seed:peer ratios on the actively pumping torrents. If the ratio on the new request is worse than on the active ones, preempt the best seeded active torrent and service the new one. Otherwise, reject/ignore the request. To my mind this increases the availablilty of (unpopular) material within the community, though this might come at a (very slight) speed penalty (to popular material).

The target ratio rule employed by utorrent by default does not maximize availability if the typical user downloads new torrents faster than utorrent takes to reach the seeding target on existing torrents. This is particularly manifest on popular (up-to-date) material where seeding is very good (not to mention private trackers). These torrents then sit there at < target ratio for a long time, preempting the entire back-catalogue from seeding.

(*) DeadWringKnight worried in his first reply about my low data rates when seeding everything. I don't actually understand why these low rates come about. Surely, any client faced with a choice of peers in a swarm would gravitate towards the faster peers (and stop requesting pieces from me)? In other words, the fact that a peer is happy to accept my trickle should indicate that that peer is desperate to get anything at all, no? And is therefore a sign that my seeding everything (albeit slowly) serves the community better, no?

---.---

Since I posted this reply, I played a new game. I noticed that the actively seeding torrents remained the same for a as long as I watched them. (The selection was not bad, incidentally, some old, some new.) However, bandwidth utilization appeared to decrease steadily. So I decided to manually pause the slowest torrent. For a long time ( 5 min?) after that, only 3 torrents would seed. Bandwidth utilization remained the same, ie the remaining 3 torrents took up the slack thru higher data rates. At last, a new torrent started to seed. Bandwidth was immediatelty back up to capacity. Is this the ISP? Does it take them time to cotton on to my game? To identify my torrent activity? Then throttle it? If this is the case, would it not then be sensible to rotate active connections on a regular basis? Incidentally, the newest torrent now shows by far the highest data rate...

---.---

Sorry to pester some more: since the new picture has established itself, more and more bandwidth amongst the 4 active torrents has gravitated to the newest arrival. Is this utorrent? All those torrents have "normal" bandwidth settings. Data rates on the other 3 have fallen off a cliff - so much so that the avg upload speed on the slowest active torrent is now (manifestly) below slow_ul_threshold.

Third question:

What governs - assuming "normal" bandwidth settings for all torrents - the bandwidth allocation to each active torrent? Why is it not more evenly spread? Is this the ISP or utorrent?

(In fact, on closer inspection, 2/3rds of my available bandwidth is taken up by one peer in Norway. Lucky him.)

[Switeck]

BT Central throttles EVERYTHING but HTTP web browsing and maybe email during peak hours, so "hiding" uTorrent traffic with encryption almost certainly doesn't help. Just have to try running during off-peak hours...possibly using Scheduler for more control.

[ovonrein]

I have left my configuration (u/l bandwidth=30K, u/l slots=5, ul_slow_threshold=1750, target ratio=(-1),no time limit, no throttling) alone for a few days but am not happy with utorrent's seeding of my catalogue. For some reason, a certain collection of 5 torrents has made it into the seeding slots and pretty much has solidly staid there for days (even through restarts of utorrent). 3 of these torrents have huge swarms with hundreds of seeds to them - they really don't need my participation. Yet I am impotent, it seems, to do anything about it.

I have just read up on Vuze who explain in detail how they work out seed queue priority. I wish that a similarly thorough explanation existed somewhere in the utorrent documentation. From my perspective, utorrent's queue scheduler does not make sense. Time to let another BT client have a go...