Transmission

Although I've set my preferences for a seeding ratio of 1:1, as reported earlier, the algorithm used by either Transmission or the trackers is designed only to deliver DL when UL bandwidth ratio exceeds a 1:1 parity or run to a stall. This drops the tracker into 'suck mode', where its only preoccupation is to suck bandwidth to feed others without downloading the file. Reducing your upload ratio to stop the tracker getting ahead of 1:1 parity simply produces a stall. This means that your seeding preference ratio, set elsewhere and reported earlier, is meaningless unless you're prepared to give away whatever the tracker wants to take to download the file. I found the tracker would only continue to allocate download once it had exceeded, and continued to exceed, 1:1 parity ratio between UL/DL. When I reduced my UL ratio to stop the tracker getting ahead it simply runs to a stall. Fortunately, I wasn't bothered about downloading the file. I dumped it and started again and the process was repeated in identical manner - run to stall around 50% of the file. When I present 20 KB/s or unlimited upload all it wants to do is UL way past a 1:1 ratio rendering the idea of seeding a meaningless notion. I also switched off transmission and my laptop to clear any saturated registers, but the algorithm remains just the same and identical responses as reported are produced. This may be okay for people who're happy to exchange 2 or 3 times the bandwidth - or whatever the tracker wants - to get a file.

Cheers

I've tested the same file download from the Pi*ate b*y, with a different torrent client, offering a ratio of 1.5:1 in terms of bandwidth UL/DL ratio and this has stalled as well, but at around 40% of the file instead of 62% of the file. So this problem is essentially a tracker problem, in my view, rather than an issue for transmission. Stalling to extort more bandwidth from users than they've offered in exchange for a file is an old ruse. The main difference I've noted is the UL-DL bandwidth profile during a file transfer, with transmission giving far more away up front when given a free hand resulting in a form of negative equity - a weak position having already given away more bandwidth to the tracker than the file itself takes to download. The alternative client I'm currently using has an automatic UL management function, which has left me in a positive equity position this time when the tracker has decided to stall. That means, if I dump the file, it's cost them more bandwidth instead of me. If they want to mess about, that's up to them, but I'd rather it was costing them more than me to do it.

Cheers

What I did next was try a different torrent client, quite a few actually, and not without a few more problems, detailed here: http://forum.utorrent.com/viewtopic.php?id=62224

I'm pretty sure, now I've got everything running okay with this different client that when I run Transmission again it will be okay now. For me, I think my ISP didn't help things much, rather than the Tracker, and an absence of decent run-log files didn't help much either. The transmission slow-speed checklist was very useful though when I was investigating other problems. Thanks.

Cheers