09-21-2004, 05:09 PM
Just like last time, there are problems with the downloader. They still haven't updated their BitTorrent client to make it not saturate the upstream. Maybe they did, but it just works very poorly, who knows?
For those of you who are having serious downloading problems, like I was, there is hope. I wanted to try this in the last push, but I ended up joining a user-run torrent to get the wow0.9.0.exe file.
As we all know, BitTorrent uploads while it downloads, making it so, in a good implementation, everyone in the torrent benefits from everyone's uploading and downloading. It's a great way to reduce strain on servers and also decrease the overall download time (for the user). In a good implementation, users normally max out their downstream without a problem, leaving the torrent open after they have completed the download, allowing other users to catch up, and add to the total seeds.
The problem with the Blizzard implementation is that, for most unfortunate DSL users (and some Cable I believe), once the BitTorrent client has downloaded a certain amount of data, the client starts uploading that data to everyone and anyone it can find, maxing out the upstream. The DSL lines get saturated by all the uploading, and then can't download, leaving that user with a 1k/s transfer rate and a download that will practically never finish.
Temporary solution? Limit the bandwidth the BitTorrent client has available. Using a third party program, you can limit your bandwidth. This Bandwidth Controller allowed me to enforce a software cap on my line that disallowed BitTorrent from saturating my upstream. Unfortunately, it also limited my downstream, simply because the cap that was being enforced was hitting the maximum.
When you reduce the overall maximum, the DSL line doesn't get saturated. From a software perspective, it still is, but literally, it isn't. For example, I can upload at 88k/s maximum, before my line is overloaded. As I approach 88k/s, latency on all other internet communications increases; web surfing, downloading, whatever. Enforcing a software cap to your bandwidth only partially solves the problem; you will be uploading and downloading at a good rate in BitTorrent, but you probably won't be able to do much more, since the amount of upstream you left yourself with will be completely used, and no acknowledgement packets can go out in a timely manner. They still go out, since they're queued up, but it's not the same as if BitTorrent wasn't chewing up the entire line. The important thing is that they actually DO go out, eventually.
I played with a number of upload rates, and each one I set seemed to match my download rate. For example, I settled on 50k/s upstream, and my downstream for the duration of the BitTorrent client's runtime was 50k/s. This coincides with BitTorrent theory, since all BitTorrent transfers are 1-to-1; someone downloads, and someone uploads. The distribution is uneven in practical situations, but after enforcing a software cap, it just happened to work properly.
So, for those of you having problems with the download, I bet this will help. It's trial-ware, so it'll have to be bought or uninstalled eventually, but for now, it worked well enough for me to recommend it. There are probably better implementations out there. This particular one allows you to enforce bandwidth limitations on a per-port and per-protocol and per-IP basis. I just enforced a broad "all upload traffic cannot exceed 50k/s" rule; I'm sure that limiting uploading on the ports in the 6112 range will greatly inrease BitTorrent speeds.
For those of you who are having serious downloading problems, like I was, there is hope. I wanted to try this in the last push, but I ended up joining a user-run torrent to get the wow0.9.0.exe file.
As we all know, BitTorrent uploads while it downloads, making it so, in a good implementation, everyone in the torrent benefits from everyone's uploading and downloading. It's a great way to reduce strain on servers and also decrease the overall download time (for the user). In a good implementation, users normally max out their downstream without a problem, leaving the torrent open after they have completed the download, allowing other users to catch up, and add to the total seeds.
The problem with the Blizzard implementation is that, for most unfortunate DSL users (and some Cable I believe), once the BitTorrent client has downloaded a certain amount of data, the client starts uploading that data to everyone and anyone it can find, maxing out the upstream. The DSL lines get saturated by all the uploading, and then can't download, leaving that user with a 1k/s transfer rate and a download that will practically never finish.
Temporary solution? Limit the bandwidth the BitTorrent client has available. Using a third party program, you can limit your bandwidth. This Bandwidth Controller allowed me to enforce a software cap on my line that disallowed BitTorrent from saturating my upstream. Unfortunately, it also limited my downstream, simply because the cap that was being enforced was hitting the maximum.
When you reduce the overall maximum, the DSL line doesn't get saturated. From a software perspective, it still is, but literally, it isn't. For example, I can upload at 88k/s maximum, before my line is overloaded. As I approach 88k/s, latency on all other internet communications increases; web surfing, downloading, whatever. Enforcing a software cap to your bandwidth only partially solves the problem; you will be uploading and downloading at a good rate in BitTorrent, but you probably won't be able to do much more, since the amount of upstream you left yourself with will be completely used, and no acknowledgement packets can go out in a timely manner. They still go out, since they're queued up, but it's not the same as if BitTorrent wasn't chewing up the entire line. The important thing is that they actually DO go out, eventually.
I played with a number of upload rates, and each one I set seemed to match my download rate. For example, I settled on 50k/s upstream, and my downstream for the duration of the BitTorrent client's runtime was 50k/s. This coincides with BitTorrent theory, since all BitTorrent transfers are 1-to-1; someone downloads, and someone uploads. The distribution is uneven in practical situations, but after enforcing a software cap, it just happened to work properly.
So, for those of you having problems with the download, I bet this will help. It's trial-ware, so it'll have to be bought or uninstalled eventually, but for now, it worked well enough for me to recommend it. There are probably better implementations out there. This particular one allows you to enforce bandwidth limitations on a per-port and per-protocol and per-IP basis. I just enforced a broad "all upload traffic cannot exceed 50k/s" rule; I'm sure that limiting uploading on the ports in the 6112 range will greatly inrease BitTorrent speeds.
"Yay! We did it!"
"Who are you?"
"Um, uh... just ... a guy." *flee*
"Who are you?"
"Um, uh... just ... a guy." *flee*
