Hash errors when seeding

[ruud]

I'm running utorrent 1.7.7 behind a satellite proxy on a dial-in connection, so I have rather unbalanced up/download rates (4096 kbit down, 33 to 46kbit up, depending on the quality of the line.)

I can download without any problem, I've seen maintained speeds up to 400kB/second, as long as my swarms consist of seeders only. But once I myself start seeding the download rates plummit and I get lots of 'received request while choked' messages and every torrent (and I mean EVERY torrent) develops hashing errors, eventually resulting in everybody being banned and I'm unable to seed nor receive.

These errors are definitly related to uTorrent seeding. I can surf the internet as much as I like, open as many FTP connections as I want and up/download using any application. Errors arrive only and always happen once someone in the swarm wants a chunk of any my files.

I've tried all kinds of speed limits, even as low as 3kB/second up and down, to no avail. I've lowered net.max_halfopen to 6, 4, and eventually 2 and back up again, I've patched windows many times increasing the available number of half opens to anything up to 50, to no avail.

I've tried other clients, they all suffer the same problem, so it must be some kind of setting that defaults to a value that does not suit satelite proxies..

Switching the (windows XP SP2) firewall off does not change anything to the problem.

I can't test port forwarding, better stated: it always fails. Yet the network indicator is green, indicating all is OK, and apart from these transmission errors I see no indication that I can't connect.

I've tried DHT on/off. uPNP on/Off, force encrypted, peer Exchange on/off, all to no avail. Changing the number of slots at any number between 1 and 10 per torrent does not help. Limiting the maximum number of connections from anything between 5 and 100 makes no change. Ofcourse I cannot guarantuee that I've tried all possible combinations of all parameters, but I have done my homework to the best I can imagine.

So, basically: I'm stuck.

Anyone has any idea what settings I could/should adjust in order to solve this problem?

[Switeck]

You have to view your connection as though it's ONLY the upload dial-up connection as far as uTorrent's settings are concerned.

And that means extremely conservative settings!

net.max_halfopen set to only 1 or 2. Really, any higher is nuts except for the first minute or so after starting a torrent.

max of 1 torrent at a time.

DHT, Local Peer Discovery, UPnP, Resolve IPs -- ALL DISABLED

It shouldn't hurt much to leave Peer Exchange enabled...though even it is automatically disabled for private torrents.

Upload Slots set to 1...only set it to 2 if+when you are seeding and doing nothing else.

Global and Per torrent max connections -- really more than 10 is BAD. The dial-up modem cannot handle the response traffic of more than a dozen or so connections at once.

Global upload speed...ok, we're going to have to 'cheat' a little here. Set it to 6 KiloBYTES/second...but put your torrent to LOW priority AND set the individual upload speed for it to only 1-4 KiloBYTES/second. With uTorrent v1.8 beta, your download speed will be limited to 12 times your upload speed when your upload speed is set less than 4 KiloBYTES/second. HOWEVER, you are unlikely to exceed 36 KiloBYTES/second download speed anyway.

[Firon]

Honestly, there's probably not much you can do, as it's either your equipment or your ISP.

[ruud]

Thanks for the quick responses.

Tried Switeck's suggestions in 1.7.7, but that does not help either. I had already tried the latest beta, but did will try again and will go through all the settings once more. I'll report later.

I was thinking the problem might be related to the long pipeline caused by to the satellite proxy. My pings return times are somewhere around 600mSec, which would explain why the client can't signal its chocked status in time.

However I cannot explain why one would lead to the other, i.e. why not being able to signal in time that I'm choked leads to hashing errors.

Note that when I disable the satellite proxy all runs fine, with ridiculously slow download speeds ofcourse.

----

Update:

Currently running build 10504 using switecks setup suggestions in a heavily populated swarm which I know is capable of maintainingst least 400kB/second.

Download speed thus far peaked at 25kB, avg. 5kB/second. Since upspeed is limited to 4kB I'd settle for that.

However... since not a single Hasherr showed up in peers list I was initially very happy. But then I looked at the log, which told a complete different story. Again 70% of the traffic is wasted... So I guess failing to update Hasherr on the peers list is a bug in the beta.

[Firon]

It's likely just an issue with the proxy, then... not something you could fix, I think.

[jewelisheaven]

1.8 handles hashing differently. It (TRIES) to only download parts of pieces which were bad, which can theoretically cut down your wasted downloaded data due to hasherrors (if a single 16 KiB block out of a 4 MiB piece) to under .5% of previous amounts. It doesn't help if it's bad peers but since it appears to be due to your connection... you are aware you can right click -> Advanced -> Reset Bans right?

http://utorrent.com/faq.php#What_do_all_those_flags_in_the_Flags_column_mean.3F hasn't quite been updated for 1.8 yet (but the manual is, and "F" means the peer was involved in sending you a piece which failed hashcheck... once the piece is hashed correctly F is removed and Hasherr increments)

[Firon]

That really doesn't have anything to do with his issue.

[jewelisheaven]

Then I mis-interpreted it... either he's sending bad data due to the proxy, or receiving bad data due to the proxy. If his speeds break to nil because uT bans all the peers due to the problem, that will allow easiest access to those peers again.

No it doesn't SOLVE the problem but for that you'd need to know WHAT exactly is being FUBARd with the stream. But not being able to run without the proxy complicates things.

[Firon]

His satellite proxy is the problem. It corrupts the data when he starts uploading.

[ruud]

Thanks again for the helpfull input, guys.

I think jewelisheaven is not that far off in his analysis of the problem. I do not think I receive bad data, because everything goes well as long as I'm no asked to seed.

Sending bad data would mean that the phone line is bad, but then I would have the same issue with other (non torrent) uploads, which I have not.

I was thinking the issue MIGHT be related to the different paths the up- and downloads take. In the past I've had similar problems with ftp, where uploads would be terminated befor completion. Seems somebody gets an ACK ahead of its time. Could this be because the ACK returns through the fixed line and arrives in approx. 50mSec, where the data is returned per sat-proxy, which takes 300mSes to arrive??

These ftp problems were over when I switched from astranet to skydsl some time ago. The torrent issue still exists.

Another possibility might be that some data is getting 'inserted' in the upload stream.You have to remember I get tons of 'received request while choked' messages.

What I currently do (and it works more or less OK) is to set both upload and download to unlimited and I've increased the ban-limit to 50 (!!) Also there the number of slots per torrent is set to 1 in an attempt to minimize upload traffic.

In the latest beta, as jewelisheaven indicated, the 'error recovery' is better than in 1.7.7. I currently run at 65% OK, 35% wasted, and I can live with that.

[Switeck]

Many satellite connections EMULATE TCP packets through their lines and instead use something like UDP packets for actual communication. This is because their latency is too high for TCP to be effective. Because a large portion of flow control in TCP is based on latency...peers and seeds uploading to you don't have the proper latency "feedback loop" to know when to slow down uploading to you. Nor can they get the stop request from you as fast even barring that.

Your latency visiting websites with lots of off-site ads/links on them is probably horrible, especially ones that force you to view the ads before the rest of the website loads.