What happens with wasted bandwidth?

[Klaus_1250]

I was wondering, what happens to wasted bandwidth? Is it reported to the tracker as being downloaded (e.g. does it affect your ratio)?

Does µTorrent compensate for wasted bandwidth? E.g. whenever bandwidth is wasted, I would say that the total available data within the swarm decreases.

[ludde]

Use latest beta, it gives less waste.

[Firon]

Normal wasted data is not reported, but data from hash fails is, unless ludde changed it.

[Klaus_1250]

I'm currently downloading a 8 GiB torrent (currently @25%), with 2MB chunks. I have 6 hasfiles, that would be 12MB, but the reported waste is 35MB (using the latest beta, of course :-) ). But my real question is what happens to wasted data. Is it 'lost' for the swarm?

[Firon]

I guess you could say it's lost.

[nightshifted]

Klaus: that depends.

If it's a redundant slice, it's still out there, and you already have it yourself, so as long as you're in the swarm, it's there, even if both of the people who sent it to you were the only other ones who had it and they've both left.

If it's a hash failure, maybe or maybe not: someone else besides the peer who sent you the bad copy may have a good copy of that piece.

[Switeck]

If you get 1 MB of 'duplicate data' that means someone uploaded 1 MB of the torrent you already had.

That bandwidth is totally wasted from the standpoint of helping people get the torrent completed.

Now asking whether it counts towards your upload/download ratio is a different story.

Another kind of wasted bandwidth is peers and seeds which have their upload speed set correctly in µTorrent (or some other BitTorrent program) and have upload bandwidth available, but for whatever the reason (firewalled, small torrent, lots of seeds/few peers) is not using that upload speed to help others get the torrent. That is not measured at all, though it probably could be.

[Firon]

Regular discarded data counts not towards your ratio or what's reported to the tracker.

Hash fails on the other hand are.

[nightshifted]

I'm personally of the opinion that hash fails, which are beyond the recipient's control, should not be reported to the tracker as part of the downloaded amount. (My personal opinion and four quarters will get you a dollar.)

[Firon]

Yeah, it shouldn't be, and ludde agrees, but since you don't determine the hash fail until after the piece finishes... the data may've already been reported to the tracker most likely.

someone suggested that µT shouldn't include incomplete pieces in the download amount sent to the tracker, so it can exclude hash fails if and when they happen.

What do you think?

[nightshifted]

Sounds good, Firon. Azureus 2.3.0.6 reportedly doesn't include hash fails in the downloaded amount, so I wonder how they do it: it's either don't count incomplete pieces, or adjust at the next announce. After all, you can't postpone announcing until you find yourself with no pieces that you're in the middle of getting; that may never happen until you acquire the whole download.

Counting only completed pieces in the download amount makes sense as a solution. Moreover, suppose the piece is never completed? Until it's completed you can't store it, so you don't really have it.

[Firon]

You can't really adjust at the announce, because you might end up reporting LESS downloaded amount than you had at the last announce, and that would look bad.

[Klaus_1250]

I'm all for not reporting hash-fails, it doesn't make sense as the bandwidth is wasted and couldn't have been useful in the first place.

[nightshifted]

Firon: indeed. If you get nothing that whole interval except to have thrown away a hash-fail that was partly downloaded at your previous announce, your reported downloaded amount would drop. So the only way is not to count partially downloaded pieces at all.

[splintax]

I say hash fails should not be reported, but wasted data should as you are still making an effort to upload. But whatever.

[Switeck]

Probably the simplest solution is to just count completed chunks, since those are known to be good and wouldn't require rollbacks for hash fails.

[nightshifted]

I say hash fails should not be reported, but wasted data should as you are still making an effort to upload. But whatever.

Tacks, we're talking about amounts downloaded. Your post seems to be about amounts uploaded.

Can the sender's client even know that the recipient discarded a slice as redundant, or a piece for failing its hash? AFAICT all sending has to be counted, even though hash fails and redundant slices will actually result in a net ratio for the swarm slighty greater than 1.00. (And that's all the less excuse for anyone's being a low-ratio leech.)

[Klaus_1250]

It would be nice if µTorrent could include an advanced option to compensate for waisted bandwidth. Someone can be seeding to 100%, but if there was waisted bandwidth, the available 'data' within the swarm still decreases. (as nightshifted points out). Usually this is compensated by seeding to 120% or more, but it doesn't give a realistic picture.

To make it more advanced, on a small and fast torrent, I noticed today that sometimes peers would reach 100% but µTorrent kept sending them some data for a small period. So to a small extent, µTorrent can also know how much bandwidth it waisted?

[splintax]

nightshifted: The amount uploaded/downloaded is reported to the tracker by each individual user. If you say you uploaded 10GB to a torrent, the tracker doesn't check to see if other users reported downloading that much or even if it's possible. That's why ratio cheaters exist. (But tracker admins check this stuff out, usually, and ban people using the cheats.)

[nightshifted]

Yes, Splintax, I've known that for almost two years.

As it is, most clients I know of do not include redundant slices in the download totals, but of course they do in the upload totals, as the sender cannot know that the recipient discarded a slice as redundant.

Moreover, when there are zombies in the swarm, or when a torrent is running on more than one tracker and some users are cross-announcing, or when a torrent is using both a tracker and DHT, there can be transfers between a peer who is announcing to a given tracker and a peer who is not. Cross-announcers themselves report their grand totals to every tracker they're using! So we already have many situations where a tracker's grand total reported upload by all peers through the history of a torrent does not equal the grand total reported download.

I daresay that, except for a tiny private swarm of invitees, it would be very surprising if they ever came out equal. Redundant slices alone are virtually inevitable, even when there are no zombies, no DHT, and no cross-announcing.

Excluding hash fails from the reported download amount would not make things worse, because nobody expects equal totals now.