Seeding Efficieny

[shawf]

I have low up bandwidth (256kbps) and seeded 6.9gb file. What the strange is, as I have the first source, for %99.8 availability. (1.998 including me) and i have uploaded 16gb. A share ratio of 2.320. I calculated %0.2 portion is about 12 megs. I have uploaded about 200megs still and availability just increased from %99.6 to %99.8. It seems client is uploading same parts that uploaded. Why client behaves like this, while there is parts that not uploaded yet?

Isnt it possible to assign a counter to each piece and upload lower ones first?

[Switeck]

µTorrent should be uploading rare parts to begin with...but not all BitTorrent clients intelligently request the rarest parts.

Also the 1 peer with 99+% may intentionally be not becoming a seed due to being on a hostile ISP that cripples upload speeds when seeding is detected.

[shawf]

I don't expect full efficiency. Due to client closes, torrent abortions etc. This includes ISP related problems so well. I wonder whether utorrent requesting rare parts.

I think slow bandwidth seeding needs abit improvement because i have seeded 6.9gb file and it took 16gb upload to make seeds. This seedment totaled about 12 days. If it was more efficient, say 1.300 ratio it would took 7 days to seed.

Also I realized that it calculates availability to according to connected peers. Not non-connected peers. I don't know how utorrent handles rareness information, if it relies on availiability according to connected peers it would be inefficient though. If you are only seeder.

I did not use initial seeding because somewhat, client can not download from me or it is not using full upload bandwidth.

I don't know if you want to implement this or not, or implemented, my idea is this.

This is for one seeder scenario. For multi seeder mode prioritizing pieces is not so important as only seeder mode.

Technically, in best situation i should upload whole data once. If the inter network between clients is very good, as I upload data it should replicate each other well. And this ends 1.000 share ratio and 1.000 availability ratio.

With repeated data or not, I will upload whole data once because I am the only seeder so my aim is to make more available seeders. I have to because i am the slow seeder and first source. Why should I upload same data again while non uploaded data is waiting.

So I assign seperate counters for each piece. When a piece has been uploaded I increase it once. If a client wants a piece from me, it has to pay for it. Paying for it is uploading it. So, most valuable pieces are rare pieces that client requests high valued rare piece. I upload you benefit so you upload and help me. It is rare piece because uploaded not yet, client will hit a piece that counter has not been increased. Increased counter means that piece is downloaded from someone else, so if a client requests that downloaded piece utorrent can assign lowest priority to that request. Means i have more important to do so wait for me to do these important jobs or get from another client.

You may think that that client can not get that part for a long time. But keep in mind that client have to wait to complete because i am the only seeder. If you want downloaded piece from me it means you are selfish because you steal other ppls time. If you don't upload to other ppl, ppl will suffer because of you. Anyway you still have to wait 7 days, so what is the point of uploading that piece before. I have uploaded that piece and i have lots of pieces that i have to upload 7 days. You should wait that too. After 7 days i can reupload that missing parts again that lost due to technical or practical experiences. That is the approach.

But I don't know this system has flaw for multi-seed mode and it is abusable. I haven't think about these scenarios.

[jewelisheaven]

If you weren't running in 'initial seed' mode (AKa super seeding) then 250% uploaded for 1 more seed isn't as uncommon as you'd hope.

Edit: http://dessent.net/btfaq about covers some of this. You can also check out Shad0w's site http://bittornado.com

[funchords]

I did not use initial seeding because somewhat, client can not download from me

I have seen the problem of clients that cannot download while in Super-Seeding mode. The same clients suffer this problem regardless if the seeder is using uTorrent or Azureus.

or it is not using full upload bandwidth.

This is normal at the beginning when Initial Seeding.

Suggestion: Next time, to avoid this problem, do not enable Initial-Seeding until the availability is between 5% or 10% (not including yourself) or until you have more than 20-25 peers. By doing this, you upload at full speed from the beginning. You also ensure that you get a core of interconnected users that is large enough to efficiently spread the rest of the data that you upload, but the small percentage that you've already uploaded is still likely to be unique since it was such a small percentage. You'll still have some clients that will sit there stupidly, unable to download from you -- but they can download/upload with everyone else in the swarm and they're still reporting useful HAVE messages to you.

And with a very large torrent, and a very small upload pipe, I also recommend that you change the piece size from the default (2M or 4M) to 256k or 512k. For a little extra incoming bandwidth, you make the task of getting a sufficient core of new seeders a lot easier.

[shawf]

Thanks for suggestions, I'll take account of these.

[The8472]

Btw, if the clients you're uploading to do their jobs well then superseeding is not always necessary, there are 3 things you can do about that:

a) ban all clients that don't follow the rarest-first-strategy properly (mostly bitcomet, bitspirit and other misbehaving clients)

make sure you don't upload too fast to individual peers (upload to more peers instead). If you upload to a peer faster than he can spread what you've uploaded then it will take longer until the pieces he got will spread throughout the swarm and thus increase the time where other peers (even the well-behaved ones) might request the same pieces instead.

c) if it's a multifile torrent... ban everyone who does selective/sequential downloading... that's an incredibly stupid behavior if the availability is low.

[shawf]

a) banning misbehaving clients maybe good option at first. But as counter if they start to identify themselves as utorrent. I don't know whether it is possible, it seems it should be possible. What will happen then?

c) how do you understand a client doing selective or sequental downloading?

As i don't see alot statistics about seeding. Statistics seems for more downloading. And how do you ban specific clients or ip blocks?

(edit)

Result of initial-seeding

First two upload segments are while normal seeding mode.

Last segment is while initial-seeding mode.

[Switeck]

A problem with banning abusive clients is some of them go into a connection frenzy, and will attempt to reconnect many times per second. That early BitComet versions (pre v0.70) does this even AFTER being connected (trying to make more connections to the same ip) is just one reason why I think it's junk.