Seeding issues - uploaded double and still no completions

[drewb0y]

I switched to uTorrent after being a diehard azureus beta updating the beta almost daily freak, mostly for the lower resource usage.

Decided to upload my first torrent using uTorrent and i thought i had all the options set well.

Well, as of now, I have uploaded 9.55Gb of a 3.86Gb iso DVD Image, and stilll there are no other complete files out there other than my initial upload.

I did not have this issue with az, i could simply set a file for superseed and it would just work,

in uTorrent the optionas are to seed or do initial seed. the only way i have noticed availability go up was with regular seed and not initial seed. Is there something I'm missing here?

[Switeck]

Azureus is a little better at dealing with hostile BitTorrent clients.

If you don't have a lot of peers in your swarm, you could try banning the 1-4 highest % complete peers by ip using ipfilter.dat -- just remember to unban them when done!

[lblisters]

I have the exact same problem.

I've been running utorrent 1.6 build 474, and it is a fantastic client.

I recently uploaded my first torrent, 7G of data. I have poor upload bandwidth, and 100+ high-bandwidth peers eagerly distributing each new piece among them, nearly all within 1% of the total availability. I noticed I was uploading 3G per day, but torrent data avilability increased by only 1G per day. I enabled "initial seeding" mode, a few days later the efficiency remains identical.

This really seems to violate the super-seeding principle of minimizing data upload by uploading each piece only once to the greatest extent possible.

I'm going to restart the client and see if efficiency improves.

[Switeck]

lblisters,

Sounds like cheating clients on those torrents sucking up alot of your upload bandwidth and not giving it back to others. They're QUITE common, but not always easy to spot. You'd have to monitor ips, as they may be connecting and getting a bit then dropping to reconnect...so you'd not see them continuously connected and leeching large amounts from you. Hit-and-Runners, in other words.

[lblisters]

Switeck, thanks for the suggestion.

I thought super-seeding would wait to upload a 2nd piece to a leech until that leech had passed the piece to others and I'd seen other leechers in posession of that piece? In which case cheats might be able to get data from me once, but that's it. Even if half of the 100 leechers were persistent cheats, it would only cost 50 wasted pieces before I learned which peers weren't sharing... and even if that half kept cheating, with "initial seeding" on I'd expect my efficiency to be a little under 50%.

Also, although cheating clients might be common in the wild, this is a closed community and a non-DHT torrent. The tracker bans lots of dodgy torrent clients, almost 100% of my peers claim to be using utorrent or azureus. I would be really surprised to learn that there were so many cheaters, that they could knock my efficiency down to 33%!

... after restarting utorrent and letting it run overnight, it seems to be even less efficient than ever... 1G uploaded but only 2% more of the 7G torrent became available. Could there be some problem with turning initial seeding on halfway through an upload? If I restart the client while initial seeding, does that throw off the algorithm and make it start over?

I understand initial seeding doesn't guarantee max upload bandwidth, or shortest time to completion. But it tries to guarantee the most efficient upload, and that goal seems totally incompatible with the efficiency I'm seeing.

I'll keep an eye on my peers list for evidence of cheats.... you may be correct but it is hard to believe that could account for what I'm seeing.

After last night's poor efficiency, I'm worried that "initial seeding" has problems and is hurting more that it helps. For now I'm going to try turning it off... I can't imagine even random algo being as inefficient, especially when most of the leechers are within 1% of total file availability.

Note: when I switched from default algo to initial seeding, the torrent data was a bit over 50% availability, resulted in efficiency about 1/3... last night when i restarted the client it was about 80% available, since then efficiency has been closer to 1/6... seems to roughly correlate to what you'd expect if initial seeding mode started over and upped each piece once, with no regards to what was available from earlier seeding... is this a possibility?

[lblisters]

Update - since switching from "initial seeding" back to default algo, my efficiency increased.

For the record, here are my notes on efficiency as I played with the settings.

Time Log:

0h: started upload of 7.3G torrent with default algo

~3 days: ~54% available, ~9G uploaded; I switched to "initial seeding"

~4 days: 67.4%, 11.9G

4d21h: 79.1%, 15.3G; reboot computer. still in "initial seeding" mode

5d10h: 81.2%, 16.5G; give up on IS and switch to normal seeding

5d20h: 95.0%, 18G

Efficiency for time intervals, expressed as G made avail / G uploaded

(thus normalized against length of time interval and upload speed, so directly comparable):

first 3 days default algo: 44.1%

next day initial seeding: 34.0%

next 21 hours initial seeding: 25.3%

[here I rebooted computer]

next 13 hours initial seeding: 12.8 %

next 10 hours normal seeding: 67.6 %

From very early on, there were a large number of leechers with ample bandwidth to keep every at the leading edge of the pack. Nearly all peers were within 1% of total availability at all times. My upload bandwidth was approx saturated the entire time (torrent was capped at 45k; my upload bandwidth varies from 40 to 50k)

Hope this is helpful

[Switeck]

Also, there could be issues with firewalled/unfirewalled peers. The firewalled peers, no matter how much data they get, have a VERY hard time sharing it with unfirewalled peers -- since they cannot connect to other firewalled peers at all.

If you firewall your µTorrent, you will see just how horrible the sitatuation is...but as a seed that might mean seeding to fast+STABLE unfirewalled peers that can upload fast to others.

I think initial seeding is being sabotaged by peers that disconnects before they get a complete piece, so they may end up with lots of unfinished pieces (that can't be shared) which really hurts the distribution.

[lblisters]

Thanks against Switeck, interesting information. I connect through a D-Link DI-514 router. I am forwarding my utorrent port, and tracker site confirms my port is open.

Clever idea to try blocking incoming connections, so that I can only upload to those accepting incoming connections, who in turn will be better able to seed.

This explanation is probably the most plausible I've come across. Still...

Doesn't IS protect against non-sharing peers? If they have so much trouble uploading, they shouldn't keep getting pieces from me.

If non-sharing peers did keep getting pieces from me, I would expect to see more of the available data hoarded... if more than half my uploaded pieces weren't being shared, I'd expect those half to be posessed only by the non-sharing peers, spread between them. In that case I'd expect a bigger gap between the total amount available and the amount posessed by all the people tied at the leading edge of the pack.

Also, if data was hoarded by non-sharers, it should still show up in the total availability.

EXCEPT... I don't really know how utorrent decides which peers and pieces to try. Is it possible my upload bandwith was saturated because I kept retrying pieces to proven bad peers, because there weren't enough good peers to keep it saturated otherwise? But that would hardly be in accordance with the principle of super-seeding.

Still, according to the "official" announcement the client should block on peers until they share the previous piece, so peers who had a hard time sharing would rarely get pieces from me.

My upload speed was saturated the whole time, in theory meaning I had an ample supply of leechers who had shared the previous piece, perhaps trickling out pieces to poor sharers who had been blocked while they were unable to share.

I can image a case where a cheater was able to screw things up for everyone... if they were able to keep reconnecting as new leechers, with 0 (or any amount I suppose) data, and trick utorrent into thinking they weren't a proven non-sharer. If the cheater was able to keep a dozen clients open, and reconnect them immediately after getting a piece, and appear as a new leecher each time, and if perhaps utorrent put new leechers at the front of the queue, then they might be able to grab more than half the pieces from me. This would lead to trying every piece twice and a 50% reduction in efficiency. Super-seeding mode might be more susceptible to that kind of attack, explaining the worse performance.

I've looked at the peer list a few times, and haven't seen people at 0%. Sorting by IP, I see a few cases of 2 or 3 peers connecting through the same provider, but nothing suspicious.

Is there any way to get more a more detailed log, that might show evidence of a cheat such as frequent new connections from the same IP?

Are any of the advanced options relevant to the problem or helpful in trouble shooting? They're all at default settings.

EDIT: I've just read http://forum.utorrent.com/viewtopic.php?pid=226093 although I don't see cheaters now, the torrent is 97% complete... they might have finished and disappeared.

[lblisters]

I turned on all columns in the peers window. I see a few leechers with "queued" of 32000. They are all getting uploads from me. Nobody else has any queued amount.

Is this unusual? Are they the best sharers? Cheaters? Am I only seeing values for people I'm uploading to?

[Switeck]

Ironically, those uploading without a limit almost certainly cannot download from you the best. They're so choked that you'll be lucky to send to them at 1 KB/sec...and even that will be bursty.

Those that can very quickly download from you may be able to do so because they set their upload speed at 10 KB/sec or less even though their line may allow much faster uploading.

Those 2 behaviors have been a common feature of file-sharing programs/networks since I started doing this back around 1999. BitTorrent protocol attempts to minimize the latter's damage but does next to nothing for the former.

I'm guessing, but I think that queued amount refers to the number of unserviced bytes they want uploaded to them at the moment. Basically, 2 sections of 16 KB each. The peers are probably trying to keep 2 "future" sections of 16 KB queued up so you'll keep feeding them even if they miss a new request for a couple seconds.

[lblisters]

Thanks for the tips. I've since learned more about cheaters. Too bad I wasn't paying closer attention to peers during my upload, I did not have a chance to determine whether this was part of (or all of) the problem. I'll pay closer attention next time.

[Switeck]

I'm watching too, as a result of what you've posted here, on torrents that I'm seeding.

I see BitComet clients (and clones) attempting to make multiple connections and/or quickly disconnecting and reconnecting, causing µTorrent to usually lose download/upload info on them.

I've even banned a couple to see if it improves my lackluster upload speed during 'bad' times.

Usually, I am uploading at my max speed almost perfectly flatline.

But sometimes it goes ragged and bursty -- and only rarely bursts up to max upload speed.

I am at a loss as to why this is happening while I am connecting to 10+ peers on various clients that are missing large sections of the torrent.