seeds/peers and availabilty columns

[ady4um]

I read several posts and large topics about seeds/peers ratio column. This column was added in 1.8 beta. Several users claim this seeds/peers ratio is a good info to have, for several reasons. Others claim users should use calc, and this info is not a good parameter for anything. Before it gets to the final 1.8 (and part of the users getting used to use it), I would like to ask about the possibility of changing this column.

People could sort, or pioritise, or whatever, using seeds/peers, but this could be not so good in several scenarios. A swarm could have many more peers than seeders (seeds/peers low ratio), but the torrent availability could still be in good condition.

The opposite could also happen. A "regular" or "good" seeds/peers ratio may be saying the torrent is dying, there are not so much peers left, and the last peers are just reaching 100% of the torrent.

Those are just examples, since seeds/peers ratio says nothing about the current situation or the torrent (its availability). Just for reasoning purpose, the seeds/peers ratio could stay steady for several hours, whlie the whole availability is growing (healthier torrent). Moreover, peers with less pieces could be entering the swarm while peers with more pieces could be getting out of the swarm, so the seeds/peers is steady, but the availability is lower (not such healthy as before).

IMO, if a torrent has a "good" avalability, that means it is more probable for users to download the whole torrent. The source of the "availability" could be peers or seeders.

All this of course does not consider the dl and ul speeds of the swarm, but the seeds/peers ratio neither.

Moreover, in this examples, people would be prioritizing the "wrong" torrent, if they were using the seeds/peers ratio.

So, I'm thinking a ratio where peers, seeds AND availability could be of use, for the same purpose the previous seeds/peers ratio was requested.

This ratio could *replace* the seeds/peers ratio, so people claiming too much info or too much columns are possibly hurting more than helping wont get upset. And if so (replacing), it would be wise to replace it before the final 1.8 version comes out. Of course this is the devs decision.

For instance, a A/(S+P)

where:

S=seeds

P=peers

A=availability

But, since (S+P) >= A, this will limit the ratio between 0 to 1. the inverted ratio

(S+P)/A

will start from 1 and up, making "ranges" of "good" or "accepted" or "problematic" ratios easier to manage and to differentiate from each other.

In most cases, this proposed ratio would be leading to the same direction the seeds/peers ratio would, but "correcting" the situations like the ones I described above.

If the mods and/or users like this suggestion, please feel free to move this topic to the appropriate category (and even try to implemented in 1.8) .

Thanks in advance.

[Ultima]

Not happening for 1.8.

I don't really see any reason the column itself needs changing either. The point of the column wasn't to give an absolute sense of swarm health. In addition, availability can't be known until the client is actually connected to the swarm -- what of those torrents that are stopped or queued?

[ady4um]

Ultima, I'm not saying the seeds/peers ratio column was added to show swarm health. I'm saying people were making points for and against adding it, with several reasons. I'm not describing *every* reason I read about, and I'm not giving here the full and complete picture. But, since I read in the forum people do use this ratio to make decisions about torrents, I though maybe a similar (improved, IMO) ratio could be used instead. Some of them said they use it to somehow prioritize, or to estimate the health of the torrent, so even if the reason for adding this column wasn't for that, users could use it for that anyway. If this kind of use hurts (at least in some cases) the swarm, then I thought my proposal could be useful. That does not mean it doesn't have its own weaknesses though.

"what of those torrents that are stopped or queued?"

There are several columns that show nothing when the torrent is inactive. They still are useful. Even the seeds/peers ratio column is not showing anything useful if the torrent isn't actively checking this info. And for that matter, mine was just a proposal, and if this can help the devs and / or users, maybe they can think of every little detail about my proposed column (and post it here).

Moreover, maybe they could think this is *also* a useful parameter, for whatever reason, and add it to the list, instead of replacing the seeds/peers ratio column. I suggested *replacing* the column because of the potential misuse of the seeds/peers ratio, specially being my proposal very similar and without some of the "misuse" cases (IMHO).

BTW, What are the reasons for adding the seeds/peers ratio column?

[Ultima]

Even the seeds/peers ratio column is not showing anything useful if the torrent isn't actively checking this info.

Tracker scrapes return at least a more reasonable estimate of the seed and peer count than it does an estimate of the availability (it doesn't return the availability at all). What you're suggesting is basically saying "throw this column out if the torrent isn't started," in which case it takes away a large reason behind the original request -- to be able to (relatively) quickly judge which torrent to start. That other columns don't do anything when the torrent job isn't started is completely irrelvant.

[ady4um]

OK, I see your point about quickly judging which torrent to start. Still, I would like to point out some things about this proposal.

First, If I only added a torrent and I didn't even started it, could I (ut) already know the amounts of seeds and peers? (Please clarify this for me)

If I (ut) can't, then I still can't use the seeds/peers ratio to decide which torrent to start. If this is the case, I would have to connect to the swarm anyway (start the torrent's job, at least with all files skipped). Making this first connection to the tracker, would it lead to find a good estimation of the torrent's availability? If so, then would my proposed ratio could give a better "prioritizing" method than the seeds/peers ratio?

Second, let's say a user wants to use this seeds/peers ratio column the way you described it, having several ("many") torrents. If I understood your point correctly, ut communicates to all the corresponding trackers, brings the seeds/peers ratio, and the user could decide, among several torrents which torrent to start (which, according to descriptions here in the forum, we could be talking about just 2 or tenths of torrents). I understand this could be a future queuing rule feature, or the user could just sort the jobs list by this column and simply start the first torrent. So, ut will be trying to estimate this on all listed torrents, even the ones that are not active (not even started)?

Third, I didn't define *a* reason to replace this column, or to propose a new one. I just mentioned that several users are requesting this seeds/peers ratio column for example for prioritizing, and that's a very similar reason to the one you gave. I see the problem of estimating the swarm availability before even starting the torrent. But this is like promoting a not-so-good way of estimating the health of a torrent. I mean, if the seeds/peers ratio column is *not* giving a good sense of swarm health, then why users should choose *this* column/method to prioritize a torrent over another?

I have read many times about users thinking "more seeds automatically means a better torrent than that other torrent which has less seeds". Then, some other user would answer "actually, it depends on...". Well, again, the seeds/peers ratio is just 1 parameter, and does not mean a torrent is better than other. Maybe the intention is not "this column says which torrent is healthier/better", but since many many users already think this really *is* saying that, users would (mis)interpret as ut "endorsing" (promoting) this method.

Please understand I'm not saying all users are requesting this ratio for this (misused) reasoning. I just saying that I read many of them requesting this ratio for health-torrent-measuring reasons, and not so many of them about other reasons. Maybe the devs just thought this ratio is better than no ratio at all. I am not so sure this is better than no ratio at all, but that would be just my particular opinion, and I'm not *the* owner of *the* truth.

As you yourself said, this seeds/peers ratio column is not giving an absolute sense of torrent's health. Anyway, many users will actually use it that way, simply because they are already thinking it is. Actually, this *could* lead to hurting even further swarm's health. I'm just trying to contribute my 2 cents, so to avoid promoting bad practices or misconceptions.

But even if I am wrong about the seeds/peers ratio column, what do you think about my proposed ratio?

(SEEDS+PEERS)/AVAILABILITY

Oh, and I'm not saying this *must* be blank if a torrent was not started (I just don't have every answer). I just presented a first idea. I'm not a bittorrent protocol expert or anything like that, just a simple ut user. Maybe the devs could think of what to do with such a column in every torrent's status and every case, but this could be a simple start point. And as I said before, the devs could think that *replacing* the seeds/peers ratio column by this idea is not a good decision, but maybe *adding* something like this in the future could be a good one.

Sorry about the long post.

[thelittlefire]

Availability is constantly changing since (at least for uTorrent) it only takes into account the CURRENTLY CONNECTED clients. Therefore ANY calculations based upon raw swarm statistics and current availability are inherently flawed IMO.

To find out the swarm's numbers, go to Advanced screen in Preferences and turn ON bt.scrape_stopped. That will perform a scrape at the tracker's update-interval to keep appraised of swarm peercount. This is an advanced setting because by default uT already does this on QUEUED torrents, in order to theoretically rotate the best candidates for running torrents to the top of the queue.

[ady4um]

Therlittlefire, I understand that getting a "good" estimation of the raw availability is not so simple and quick. I'm not saying that the seeds/peers ratio column is useless and that my proposal is better in every aspect (maybe it is?) My concern was user misuse of the seeds/peers ratio column, for example in a way that could potentially do more hurt than help swarms (according, again, to the many posts I read about this). So I thought of a possible sugestion. Maybe a more simple ratio (comparing to my previous proposal) could be:

(S+P)/A

Where these numbers are just related to the current conected peers and seeds, instead of all the ones in the torrent swarm.

As I said, I'm not an expert. I don't really know if this is really simpler to estimate (I suppose it should, since an active torrent is already estimating - accurately or not so much -those numbers anyway). I don't know if this is more accurate from my previous proposal. And I don't really know if this is more helpful than the seeds/peers ratio column. Maybe all these columns are really pointless? Or maybe both should be added (to complement each other)? I am just acknowledging the potential misuse, even if the reason for adding this column is for a good cause.

Moreover, let's say that the seeds/peers ratio column is relatively simple and accurate. Does this mean most users will use it wisely? Being simple to obtain is not enough to be useful or to be wisely used. Is it better than having no other ratio involving seeds/peers? Well, maybe, if the probability of misused (and hurt of swarms) is high, then the swarm could be better without users using it?

But since the devs already decided about this point (by including this column in ut 1.8), I though of (maybe) another way. This was a first proposal. I can see know 2 problems, accuracy, and (maybe) generating more data interchange to achieve a maybe more useful ratio.

I would like to know not just the cons of this proposal, but maybe someone saying something that would sound like pros. After that sort of pros and cons discussion, it would be the devs job to find an acceptable balance between them.

Maybe the currently-connected numbers for calculating the proposed ratio is the one?

[thelittlefire]

Well, I think S+P/A only taking into account connected users would be useful... but think of a good message to put there for the times where A = 0.0 (divide by 0 makes "bad things happen")

I believe this column isn't even on by default.. but I could be wrong, I haven't used 1.8 as much as 1.7 lately. With default column settings it should be readily apparent what most users WANT from the client whether or not they THINK they "need" it. Getting a quick idea of swarm health, incorrect or otherwise is a very valid point for making this column readily available. Overall your logical explanation of the argument is mainly what convinced me though... I never cared much for raw swarm statistics, given all the 65535 peer swarms you see on index sites these days.

[ady4um]

>"taking into account connected users "

>"times where A = 0.0"

Thelittlefire, these 2 conditions are not going to happen at the same time (there could be potentially an exception, though). If I have at least 1 peer connected who has at least 1 piece to share, the availability wont be 0. The exception would exist, when I just start the torrent for the first time, I don't have any pieces (my own availability is 0) and the peers I am getting to connect to are also in a similar condition - their availability also being 0. I suppose a very very very new torrent, or a dying and very old one, could be potentially in such a situation. These should not be a problem for the devs if such - or similar "ratio" - column is added. Adding the condition of the availability being "not 0" for the column to be calculated should solve it, in a similar way other columns are (the share ratio column before getting and/or sharing any piece is an example; connecting to just-seeds-and-no-peers in the seeds/peers ratio is another one).

You also wrote the calculated column as "S+P/A". For other people reading this topic, I would like to be specific. The proposal was (S+P)/A. In math, those brackets make a difference.

>"I believe this column isn't even on by default"

Well, the column is off by default, but I am not so concerned about people not using this info. Those are going to use ut the same way than before, so a "misuse" in this cases is not an issue; people who would like to use this seeds/peers ratio *are*. I'm not saying everyone will use it to make wrong decisions because of misunderstanding it. But according to many requests about this seeds/peers ratio column, this misuse could be potentially widespread. Even if a user is not *displaying* the column, a future prioritizing-rules-feature could use it (even without displaying it). Eventually, users "exploring" ut features will see this column (even if right now the default is "off"), and again the potential misuse is there, making things even worst. I'm not against this column. I'm just concerned about consequences of its misuse.

>"Getting a quick idea of swarm health, incorrect or otherwise is a very valid point for making this column readily available."

Well, that's my whole point. If people think the seeds/peers ratio column is a *correct* way to measure swarm health, they'll be wrong, as Ultima already said in this topic. This is just a parameter, which could be saying *something* about the swarm status. There are many situations where a higher seeds/peers ratio (compared to other torrents) does not mean the torrent is "healthier" than others.

People not understanding this could misuse it, hurting even futher the swarms, and making decisions against their own interests. This has happened before, with multiple files torrent and selective downloadings for example. Misuse and abuse of selecting downloading hurts the swarm, and users negatively affect theirselfs without even knowing it.

It is very probable this seeds/peers ratio is going to be there in the final ut 1.8 version. IMO, it would be wise if immediately after the release all ut documents could point this potential misuse and explain it the best it could be explained. It could be in the faq section, a sticky in the forum, included in the manual both in troubleshooting and in the explanation of the column itself... I think, "it is better to prevent..."

Not showing the column by default, and explaining this column better (and its potential misuse) are good things, but thinking of an alternative (or a complement) info for those trying to prioritize according to "torrent/swarm health" it is too (even better).

Maybe the devs could propose something about it. Could "(S+P)/A" be a good add? Is there any idea from this starting point? Maybe, am I just very wrong about the impression that many users could misuse this seeds/peers ratio? And, regardless of the seeds/peers ratio, is this proposed info of any good use and worth to add?