bt.initial_seed_fast

[Honeyfrog]

In my never-ending quest for truth, justice, and the faster initial-seeding, I propose:

bt.initial_seed_fast 0,0

Q. What is it for?

A. Preventing underutilization of allocated upload bandwidth.

Newly released torrents can be (and usually are) agonizingly slow in initial-seeding mode. It is particularly bad when there are exactly two connected peers. This, combined with the low percentage completion, has the effect of causing many potential peers to think, "I come back later when it's faster." In other words, at the time I need them most, peers are inclined to hesitate.

What bt.initial_seed_fast will do is turn off peer-retrade verification during initial-seeding when certain conditions are not met, permitting the client to simply throw pieces out the door as fast as it can in sequential order. (In fact, the mode is simply regular-seeding done in sequential order.)

x,y

x is an integer between 0 and 100, and represents the availability percentage of the torrent. bt.initial_seed_fast will be in effect when the availability percentage is LESS than the entered value. (A value of 0 means it is off by default.)

y is an integer between 1 and 256, and represents the number of connected peers. bt.initial_seed_fast will be in effect when the number of connected peers is less than the entered value. (A value of 1 means it is off by default.)

If either x or y is met, bt.initial_seed_fast engages.

Good values for x and y: In my experience, x=20 as about right. I'd guess that a good 95% or more of pieces sent out prior to 20% are returned to the torrent prior to establishment of new seeds, regardless of the "leechiness" of the peers they are sent to. y is more variable, and depends upon your available bandwidth, and the sort of peers you're uploading to (15 to 20 connected peers is generally about the point a torrent caps my throttled cable connection when I am initial-seeding and uTorrent is verifying peer re-sends).

==//==

(See also this proposal.)

[jewelisheaven]

Initial Seed mode is for limiting upload overhead by only uploading each piece once (on the first upload where ratio < 1.0). This rewards peers who share their pieces faster by giving them more data. Eliminating the check for your SENT piece to be HAVEd by another peer is not in the specification for said option.

Any search for sequential seeding or sequential pieces or sequential piece sending will return responses both opinionated and with proof that bittorrent is not a streaming protocol.

[Honeyfrog]

<shrug> So? Stuff evolves. I think this would be really cool, and give me a lot more control toward maximizing my bandwidth. I can't fathom who, in a torrent, would object to me shipping it out faster.