Re: ADSL again

[jwb@example.com (Jim Breen)]

Jonathan Q <jq@example.com> wrote:

>> This is hugely variable.  

More variable than most people realise.

>> What matters more than anything else is the
>> capacity of the download site itself.  

Maybe, maybe not. The perceived download time for an individual user is
a result of a combination of many factors. Basically you are using a
series of components, and the available bandwidth of all of them is
fluctating all the time. What you get is the limited by the lowest
available bandwidth of any of the components in the chain.

>> If it's at all popular, chances
>> are you won't hit the theoretical speed of the line.  

True, it's far more likely that somewhere along the path between your
DSL provider and the destination site is a link that is more congested
than the tail of the DSL line to your home/office.

>> After all,
>> it only takes a few DSL users to saturate a 10 megabit link.

Er, no. The protocol that rules the waves in this area is TCP, and TCP
is far too smart to allow a few users to saturate a link. It works to
divide up the available bandwidth on a link (in each direction) in
proportion to the proffered load. If the aggregate proffered load
exceeds that available bandwidth (and in the Internet this happens almost 
all of the time), TCP slows down enough to reduce the proffered load.

>> FTP site operators gotta hate that stuff :-)

They may well love it. Depends on their business model.

>> I have switched 100baseT to my desk at work, and you better
>> believe I never get anything close to the capacity of that line :-)

Of course not. You didn't seriously think that you would?

>> How close you are to the CO makes a difference, too, as does the
>> general quality of the line.  

Again, this depends on a lot of things, including the actual DSL/ADSL
service, whether the modems are adaptive, etc., etc.  Most ADSL services
are tuned to a pretty flat rate over typical local-loop configurations. If
you are getting errors that result in TCP dropping packets and
retransmitting, it is something your provider should fix, as the
margin between a few dropped packets and a lot is pretty fine. Those
modems are usually (and rightly) right up against the SNR thesholds.

>> I know people on eaccess who
>> get pretty close to wire speed, and others who see much less
>> performance, but the DSL provider doesn't make much difference.
>> There isn't a huge difference between one vendor's DSLAM and 
>> another's (I don't know whose DSLAMS eaccess and and Tokyo
>> Metallic use, but I wouldn't be surprised if they were from
>> the same vendor; it's not a crowded market) and either way
>> it's NTT's copper.

Exactly.

>> The only eaccess users I know usually get as near to wire
>> speed as can be reasonably expected, but I've heard about others
>> using the same ISP who often get far less than that.  It could
>> be the FTP sites they use, their distance from the telco CO,
>> the condition of the wires, interference on the lines, 
>> the way they have their software configured (some people 
>> think they're smart to do stuff like changing the MTUn
>> to 296, but that *doesn't* get them faster downloads.  Usually
>> it will make them slower.  Foot, gun - arrange a meeting), the
>> phase of the moon (kidding) and solar storm activity (not
>> kidding).

Hang on. Changing the MTU up from the default, which is typically set to
suit dial-up PPP, can and will improve the throughput, except in cases
of heavy packet-dropping. Setting it higher that the maximum Ethernet
frame size is a waste of time, and anyway the MTU Discovery will or
should override that anyway.

Jim
-- 
Jim Breen  [jwb@example.com  http://www.csse.monash.edu.au/~jwb/]
Visiting Professor, Institute for the Study of Languages and Cultures of 
Asia and Africa, Tokyo University of Foreign Studies, Japan
+81 3 5974 3880         [$B%8%`!&%V%j!<%s(B@$BEl5~30Bg(B]