Seeds/peers ratio

[chaosblade]

TurtlesRock, You're annoying. Just thought i'd share my opinion

Back on topic: I dont think this statistic can really help anyone and thus the column would be pretty irrelevent. Unlike ratio which is pretty much a widely used statistic needed for certain decision regarding the main use of uTorrent - A BitTorrent Client (incase someone forgot).

[lilolee]

Well I'm getting pretty fed up of checking torrents where I am potentially the only seed by having to keep scrolling up and down the list and look.

Lets face it if you don't want to see a column you can always hide it

Lee

[Doomer]

I dont think this statistic can really help anyone and thus the column would be pretty irrelevent. Unlike ratio which is pretty much a widely used statistic needed for certain decision

Irrelevant? This Peers:Seeds is not only relevant, not only a decision factor for us to prioritize the torrents, but it is the very one factor used by Azureus in order to automatically prioritize the torrents!

Strange that not even one has mentioned this issue in this thread; I opened a new request for this issue some time ago.

I don't just want to prioritize myself the torrents based on Peers:Seeds;

I want uTorrent itself automatically and continuously prioritize the torrents, based on Peers:Seeds, without doing nothing myself, don't either look at the priorities!

This is the only, the very only capability that uTorrent lacks comparing with Azureus (and every other client lacks too)! And it's the only thing that makes me continue using Azureus. I have ~70 torrents ready for seeding, I leave the PC open and leave from home. I come in the evening, and all the day Azureus has been automatically prioritizing the most demanded torrents!

That's the whole point!

[lilolee]

Couldn't agree more.

In fact I think it is so useful I can see me going back to Azereus.

Lee

[Ojec]

Irrelevant? This Peers:Seeds is not only relevant, not only a decision factor for us to prioritize the torrents, but it is the very one factor used by Azureus in order to automatically prioritize the torrents!

Strange that not even one has mentioned this issue in this thread; I opened a new request for this issue some time ago.

I don't just want to prioritize myself the torrents based on Peers:Seeds;

I want uTorrent itself automatically and continuously prioritize the torrents, based on Peers:Seeds, without doing nothing myself, don't either look at the priorities!

This is the only, the very only capability that uTorrent lacks comparing with Azureus (and every other client lacks too)! And it's the only thing that makes me continue using Azureus. I have ~70 torrents ready for seeding, I leave the PC open and leave from home. I come in the evening, and all the day Azureus has been automatically prioritizing the most demanded torrents!

That's the whole point!

Well said. I couldn't agree more. Anyone who thinks seed:peer ratio is irrelevant can choose to hide the column, but it is the only essential feature suspiciously missing from µT.

Yes, it should be the primary factor -- if not the only factor -- in determining seed priority, and yes every other client that I've tried prioritizes thusly.

It's funny how µT can do something as trivial as resolving IP addressess, displaying a cute little country flag, when this simple and essential function is absent.

[Firon]

Look, we know that it's hard to seed a lot of torrents right now, but ludde has other priorities at the moment (namely, packet encryption). Once those are out of the way, then organization and improved seeding rules will come.

[lilolee]

Firon, don't get me wrong, I would never criticize what ludde has done. It is fantastic. I am just defending my request for this facility.

Lee

[Firon]

I know, I'm not getting anyone wrong, I'm just saying that we DO know that there's a serious lack of seeding rules and organization, which makes it hard when you have tons of torrents. Sometime in the near future this kind of stuff will get implemented..

[why_gnat]

So how did all this turn out, then? I apologize if this has been added and I'm too thick to find it. I've been through the list of changes and column list and don't see it.

Probably not a high priority but I don't understand the comments that it's a useless column. I see seeder:peer ratio as one of the best ways to manually or automatically choose what to seed from a ratio site. If I have a lot of potential torrents to seed, I sort by peers and glance down the seed/peer columns and turn seeding on/off based on that.

Adding the column should be quick, small, and simple. Sure it can be done manually but, as someone said, we can lose the ratio column because you have the up and down columns. We can lose the fancy percent meter because you have the size and download column. But I can't imagine anyone turning off either of those two columns.

I agree auto seeding based on the column would be a lot of programming since that would be mean new dialogs and functionality.

Just my dream to keep this request alive!

[Drostie]

I'm going to bump this and add my own personal support.

The most reliable indicator of how much a torrent needs your seeding contribution is the ratio of its seeders to leechers. (Better synthetic indicators could be constructed, but not with the amount of data that the BitTorrent spec presently offers.)

In fact, uTorrent already uses this in its queueing algorithm (see also Options - Preferences - Advanced - queue.use_seed_peer_ratio). But there is no column in the main torrent view to sort the torrents by their seed-to-peer ratio. Yet.

That's a real shame, because if you're me, and you've got an 0.8 share ratio on a torrent that has a 30.0 s2p ratio, and a 2.0 share ratio on another torrent which has a 1.0 s2p ratio, you'd rather help out the second torrent than the first -- but the second torrent is probably going to be throttled by uTorrent by default.

You might think that using a calculator would be enough, but when you've got two dozen torrents to look at, that's just not cricket.

So, come on. An additional column, disabled by default, which uses a property that uTorrent already calculates by default, just in case some of us want to use it. (As you can see, some of us do.)

[Honeyfrog]

I wish Azureus would cut out great wads of useless garbage so it'd shrink down to a lean, svelt bred-for-Canadian-bacon pig, instead of being the bloated lard sow it is now.

[Drostie]

I think the issue with Azureus is less software bloat and more a messy user interface. An extra feature is generally a good thing, if it is filed nicely in an intuitive UI, out of the way of a casual browser who's not looking for it, but cataloged somewhere where anybody seeking it can find it. (Azureus is on the order of 10 MiBs; uTorrent is on the order of 0.1 MiBs. While the factor-of-100 difference may seem surprising at first, remember that it only translates to a real physical size of about three MP3s in a world of gigabyte RAM amounts and hundreds of gigabytes of hard disk space.)

Azureus does, though, have a very poorly designed user interface. Which is a definite plus for uTorrent: less functionality is okay if it significantly improves the GUI. (I just think we should make sure we have those priorities straight: It's not being "anti-software-bloat" so much as "pro-simple-UI.") As the Joel on Software blog put it:

A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Unfortunately, it's never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release "lite" word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the "word count" feature which they need because most journalists have precise word count requirements, and it's not there, because it's in the "80% that nobody uses," and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can't use this damn thing 'cause it won't count my words. If I had a dollar for every time this has happened I would be very happy.

[Honeyfrog]

Application size, or even memory footprint, pale before the issue of CPU demand.

[Firon]

Azureus uses a huge amount of memory AND CPU. That also makes it bloated.

[amc1]

Technically, it's the JVM which doesn't free up some of the memory that Azureus has since deallocated, so it's not often possible to determine exactly how much memory Azureus is using.

[Honeyfrog]

Getting back on topic...

seed:peer ratio is...the only essential feature suspiciously missing from µT.

As someone who creates a lot of torrents, I have to disagree that such a thing is "essential" at all. For starters, you're not going to see every peer in a torrent--you may not even see half, so accurate reads on piece-availability are often a crap-shoot and the best uTorrent can do is preferentially seed your rarest pieces (something it does anyway) relative to what it sees. Additionally, the number of seeds a torrent will support is inversely correlated to its size and number of total pieces (torrents with many thousands of pieces more easily support entire distributed copies; likewise, small torrents that download quickly will be overrepresented in the seeds department due to many being users who haven't woken up yet in the morning to close out).

Really, though, it shouldn't be considered a client-developer's responsibility to figure out how to "coddle" lackluster torrents which are generally languishing due to suboptimal decisions of the .torrent's creator. E.g., if you post a 700mb file with 1meg pieces to a private site with DHT=off, expect minimal interest. If you post the same material with DHT=on in 128k pieces to a half-dozen sites with multiple tracker announce URLs, it'll last nearly forever provided you gave it a name search-engines can play with.

I've already suggested that newer versions have a much smaller default piece size. Beyond that, I think uTorrent is best served addressing larger bittorrent issues such as thwarting "cheating" clients and throttling ISPs.

[Firon]

piece size doesn't have the impact you think it does

[Honeyfrog]

I've got to go with my own lyin' eyes over theory here. I've experimented extensively with varying piece sizes in otherwise similar torrents, and there were noticable improvements in both initial-seeding time and unassisted torrent longevity when piece sizes were small, and especially so in torrents which were compilations of many smaller files which peers downloaded preferentially.

I did find that piece size tended not to matter quite as much when the torrent acquired a certain threshold number of peers (generally over a dozen).

Edit: Example - let's say I'm initially-seeding a 4gig torrent with 4mb pieces (so there's only a thousand). Let's say the torrent averages 12 peers and 3 of them are leeches who strangle their uploads to 1k/s. Let's say each leech, despite his completely puked uploads, nevertheless has his client configured to trade with 8 other peers simultaneously.

...It will take each leech 68 minutes to re-trade a single received initially-seeded piece to one other peer if that peer is the *only* peer connected to the leech, or over nine hours to re-trade the piece to eight other peers at 0.125k/s. In practice, however, those other peers' clients are going to dump the leech's connection in preference to trading with other faster peers. It is thus possible for the three leeches to never successfully retrade, in their entirety, *any* of the 4mb pieces they've received before the initial-seeder cycles through a second or third pass and finishes the torrent. Even if the initial-seeder's client completely rejects sending 2nd pieces to any of the leeches, the fact that new leeches continually appear to grab a first, new piece will cause the seeder to have to upload a substantial percentage more than necessary.

[Switeck]

And we can always thank the people who put in their DOWNLOAD speed for Speed Guide (CTRL+G) to make things even worse.

[Drostie]

Honeyfrog: I'm not so sure that the issue is quite what you think it is. I just want to see a (by-default disabled) column with this ratio listed on it -- and evidently some other people do too (which was why I dug this thread back up). I don't for a moment think that it's "a client-developer's responsibility to figure out how to 'coddle' lackluster torrents which are generally languishing due to suboptimal decisions of the .torrent's creator," and so on.

Rather, I want to take that on as *my* responsibility. The S2P statistic helps tremendously in that regard. (And, like I said, it seems to be a part of uTorrent's seeding algorithm by default.)

For me, the issue is simple: I have only 100 KiB/s to give, and I'd like to give it to the people who most need it. At the one extreme, I think that if I'm the only seeder on a torrent (whether original-seeding or otherwise), that torrent should have first priority.

A general criterion is harder to come by, but S2P is a decent approximation to what my preferences are. (I could talk more about some I've played with the math for, but this post is long enough...)

[DragonsDream]

thought I'd revive this rather than starting a new thread.

Wow, I must say the arrogance of some members is amazing: "I don't use uTorrent that way so therefore that info is useless and no one else should need it either"

Let me say again, "Wow"

Seed to peer ratio is perhaps the ONLY stat that matters when seeding IF you want to be a good sharer. up/down ratio may be important for your personal torrenting but is a worthless stat in deciding which torrents need your upload. For those of us with 10mb pipes, maintaining a ratio of 1 isn't even an issue. I can start a torrent at night and when I wake the next morning, I can have a ratio of 10 or more sometimes. What is more important to me is knowing which torrents actually need me.

I never want to be the person who kills a torrent, and basing what you seed on your own ratio means this can and likely will happen. "Well, I've reached a ratio of 1.5, time to stop uploading" even if you are the last peer, you just give a great big finger to all the peers between 1% and 99.9% because, hey, you've reached your seed goal.

Thankfully seed/peer ratio was added to 1.8, now hopefully, seeding rules based on that can be added as well. Not just "priority" but being able to stop if there are more seeds than peers regardless of up/down ratio and other scheduling tasks like that.

[jewelisheaven]

Scheduler overhaul for 1.9 is planned and rumblings indicate it will be "rules" based.

[DragonsDream]

cool. thanks for the heads up