-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Greg Brooks wrote: | Chiming in at this point only because the technical part of it has gotten | way, way beyond what I can understand.... | | Do I have this right: | | * I can't do what I want to do with DSL bonding/aggregation/etc to boost | outbound bandwidth. | | * There's a T1 (feh!) in my future.
Mostly. It's pretty well determined that setting up two DSL links to increase the performance of a single TCP session (your FTP file upload) is going to be more pain than it's worth (particularly if the discussion has gone way, way over your head, as you indicate!). :)
One option that hasn't been discussed a lot, however, is splitting your upload into lots of little pieces and re-assembling it on the far end.
There exist a lot of tools to do this, from stuff to let you post images to newsgroups to things like bit-torrent and other peer-peer protocols.
If you just want to move the file, and don't have to use FTP, you could use bit-torrent, seed it to your local machine (with your 'primary' IP address), then launch 2 client downloads: one on another local machine (with your 'secondary' IP address from the new DSL line) and one on the remote webserver. Bit-torrent will automagically split the file into tiny pieces and fill all available outbound bandwidth. This should easily scale to however many DSL links you wish to add, and could be fired off by a script or something to make it easy.
You also want to make sure your TCP stack is tweaked for high-latency connections. This isn't such a big deal with linux (although it can still help), but windows systems need some registry changes to work well with high-speed, high-latency internet connections:
http://www.speedguide.net/downloads.php
Tweaking your TCP settings can be critical to getting the maximum performance out of a *SINGLE* TCP session...with a bunch of TCP sessions things tend to balance themselves out. If you're already maxing out your uplink bandwidth (verified by monitoring transfer rates), you don't need to worry about this.
- -- Charles Steinkuehler [email protected]