Initial seeding seems broken since 1.8.4

[aland]

My apologies if this is not the correct forum to post such a thread, but I've noticed since updating to 1.8.4 16688 (from 1.8.3 16010) that initial seeding goes incredibly slow.

My understanding of initial seeding (and please correct me if I'm wrong) is that it the seeder will only send out each block of data once, so as to maximise efficiency.

I upload torrents to a private tracker with a small swarm, and I have read here that initial seeding only works in larger swarms, but I find that using 1.8.3 initial seeding will go full speed regardless of how many peers. I only upload about once a week, so rigorous testing is difficult.

So a few questions,

Did something change with initial seeding in 1.8.4?

Would trying 1.8.5 be beneficial (right now I've gone back to 1.8.3 because it generally seems to run torrents faster and I don't like how the sort order of blank Completed on values has changed).

I am going to be uploading a torrent tonight, do you have any suggestions what I can try? For example I can run one of the newer versions and turn on logging and paste back the results (however I seed lots of other torrents so it can be hard to see the forest for the trees).

I should mention I'm on XP 32bit.

Many thanks for your hardwork on this program

[mouser]

I also upload several torrents daily on private trackers and have noticed the exact same thing

i've found that initial seeding isn't always the best way to get things going. The only time that it does actually make uploading faster is if you have ~10 peers with (roughly, within 1-2% same completion percentage in the peerlist. If all of your connected peers have different % complete then you'll see your upload speed go up and down with a great range of fluctuation.

I wish i had an answer for you regarding what causes this and how it can be avoided. But, what i can tell you is that you shouldn't be using Initial Seeding unless you have a large number of peers. The only time I consider using it is if i have 40+ peers because at that point it's a guarantee that i'll be maxing my upload. If you are getting less than 15 unique peers on each upload, just seed it normally.

[aland]

Many torrents being uploaded to private trackers would not get that level of peers, I think I'll stick with 1.8.3 rather than update..

[DreadWingKnight]

Initial seeding isn't recommended for use on low population swarms in general because of limitations in uTorrent's implementation.

Sticking with 1.8.3 means you're unsupported.

[aland]

So initial seeding isn't working correctly in 1.8.3 then?

I'll try 1.8.5 with regular seeding..

Could initial seeding be automatically disabled if there is not many peers?

[Firon]

Initial seeding has sucked since it was first implemented.

[Switeck]

I find ok results with initial seeding if I have more than 1 torrent uploading and/or only 1 torrent of those using initial seeding.

[nanoflyer]

I think that initial seeding (aka super seeding) is probably not doing what is expected per the first note. I've seeded 12 torrent as of recent and in each case the ratio needed to finish seeding goes way over 1.0x to something like 1.7, 1.8, 1.9.

There are 30-40 connects per. It's initial seeding and (of course) I am the only seeder, so I think I fit what it's designed for.

I may be more sensitive than most because in my area I'm limited to 11 Kb/s, so big uploads can take a long time and I try everything possible to get it seeded asap.

[moogly]

No, it's not broken, it's the normal behavior.

That's why the default value for the seeding ratio is set to 1.5 because in many cases 1.5 is the minimum value from which the torrent is fully seeded when the seeder enables super seeding.

Remember super seeding is sensitive to swarm quality and size.

[nanoflyer]

1.5??? uTorrent help says as low as 1.05 is possible and that sounds more like what super / initial seeding should be doing. In fact if there were not resends nor people going offline, the number should be 1.00 (in theory). When I don't use superseeding I'm getting about the same results.

I should mention that I am a convert from another popular bittorrent client and it works like I described above. As an old programmer with software patents, etc. I don't think I am crying "wolf" on this, but I'll leave off here as I don't want to offend the people who, overall, have done an great job with this application.

[DreadWingKnight]

It's not against the design, and moogly is WAY off the mark here.

The design intention for initial-seed IS to reduce the required upload as close to 1.0 as possible, but as you've seen, implementation didn't work.

Right now the only effective client core I know of for super/initial seeding is bittornado.

[Firon]

Our superseeding ain't great. It does need some work.

[Switeck]

With certain BT clients (BitComet!) not always reporting that they've downloaded pieces, initial seeding assumes those pieces failed to upload. So ironically, those BT clients that are bad at sharing can end up being the primary peers that the initial seeder uploads to...compounding the problem.

When BT clients attempt to force sequential downloading, they too can short-circuit the initial seeding process -- because they ignore rarest-piece-first strategy.

If there's too few peers, the initial seeder is left waiting for the peers to share pieces it already uploaded...and NOT uploading anything while it waits! If the peers are firewalled, this can even be impossible.

if there's too many peers or hidden/firewalled peers, the seed cannot see when a connected peer uploads a piece to one of hidden/firewalled peers...so the seed thinks the connected peer has not shared that piece and will not be uploaded to again until it uploads to a peer the seed CAN see.

[SineSwiper]

What's the status of this? Seeding is half the point of torrents. This should be a high priority bug to fix.