So, running an FTP server, where uploading data at the max rate would be the norm, will frustrate you to no end when what you want comes piddling in.

What you are seeing isn't so much a limit of the DSL line, as the protocol you happen to be using at the time. If you are using UDP, it will work better than if you are using TCP. Here's why.

TCP and UDP are the two protocols most often used over the Internet. They serve different drastically different needs, and thus, continue to exist in parallel. TCP is a connection oriented protocol, with guaranteed delivery and some error correction built in. As such, it has higher overhead than UDP, which doesn't have those features. Thus, UDP is the lightweight protocol to use if you don't require the features of TCP, or can build them into your specific application at a lower resource cost than that of TCP.

As part of the services provided by TCP, a two-way conversation is set up, such that when you are downloading something, TCP responds regularly back to the server with acknowledgements (ACKs) that you are successfully getting what it is sending. If there happens to be an error, or something doesn't get through, TCP will request the defective packet be re-sent. The amount of data that can be sent, before the sending server has to wait for ACKs to ensure the data is getting through correctly, is determined by the Receive Window (RcvWin, or RWin). Ideally, this is set high enough so the ACKs have time to get back to the server before it thinks something went wrong, but not so high that in the event of an error, the server will be forced to re-send more data than necessary.

When your uplink is saturated, any TCP ACKs from a download must wait in line along with whatever you are uploading at the time. The general effect is to limit the downlink to roughly the same speed as the uplink – but only while the uplink is saturated, and only when TCP is the protocol being used.

UDP, being more lightweight, doesn't have this problem. It doesn't require ACKs, but then again, doesn't have any built-in way to ensure what is sent is actually received, and received correctly. Thus, UDP is ideal for, like, streaming media, where a packet lost here or there isn’t a big deal, as compared to the extra resources TCP would require. TCP is more suited to file downloads and the like – particularly binary files – where even a single bit out of place means a wasted download.With the exception of some games and streaming media, most stuff we associate with the Internet is transferred with TCP. TCP is used for web browsing, news and mail protocols, FTP, and the like.

The net effect of all of the above, is that if your uplink is saturated, with WHATEVER kind of traffic, anything TCP on the downlink will be limited more or less to the same speed, due to the ACK requirements. Without those ACKs, the download cannot continue, so any TCP downloads are restricted to the ability to get the ACKs back upstream. OTOH, as long as you have UDP properly configured in your streaming media player of choice, you should be able to watch/listen almost unaffected by the upstream saturation. (There will be an effect, any time it needs to send a message upstream, such as when changing songs or videos, perhaps, but once going, it should play with less interuption than an equivilant TCP stream would under the same conditions.)

So what if your applications require TCP? The solution then, is bandwidth limit whatever is saturating the uplink, to something less than saturation levels. In this case, that would mean setting your FTP server to perhaps 75 or 90 percent of your upstream bandwidth. Some FTP servers have that ability, as do some routers, for FTP traffic. If you don't have a server (or router) that can do that, perhaps you should switch servers. (Traffic shaping routers, unless you build your own using a BSD or Linux solution, generally, cost more than you probably want to spend - a bandwidth limiting FTP server is probably a much more cost effective solution.)

That should cover the basics, anyway.