why upload with adsl is faster than 100M ethernet ?

Iljitsch van Beijnum iljitsch at muada.com
Fri Oct 15 08:56:31 UTC 2004

On 15-okt-04, at 10:14, Joe Shen wrote:

> The
> measuring is scheduled 20packet per 20seconds, we also
> ping each hop address along the path to server. The
> result shows there is no packet loss along from
> monitoring computer to customer site, but packet loss
> increase at a special hop along the path to server in
> japan.

Pinging with 1 second intervals only gives you part of the picture. 
Some types of problems only show up when the traffic load increases. 
Try ping -f or ping -l.

If you have packet loss, TCP performance will suffer. A possible 
explanation for your situation is that the packet loss increases as 
bandwidth use increases (this can easily happen with duplex problems or 
when rate limiting is in effect) and since ethernet can deliver more 
packets within a shorter time, it's more likely to experience several 
lost packets in a row. When this happens, TCP goes into "slow start" 
and your performance is gone. With ADSL, the packets don't come in as 
fast so it's less likely that several successive packets are lost, and 
only a single packet means "congestion avoidance" which also slows down 
your session but not quite as badly.

>> Look for duplex mismatch or something similar.

> I disable autonegotiation of ethernet. So, there is no
> such situation.

It's generally a bad idea to turn of ethernet autonegotiation unless 
the equipment at the other side doesn't support it.

Did you set the link to full duplex? Full duplex and no autonegotiation 
on one end with autonegotiation turned on at the other will create the 
situation where one end uses full duplex and the other half duplex. 
(Because the other end sees no autonegotiation, it thinks it's 
connected to a dumb hub = half duplex.) With a simple ping you 
generally don't see this, but when traffic increases and both sides 
start to send packets at the same time you get packet loss. (Excessive 
collions errors on one side, CRC errors on the other side.)

More information about the NANOG mailing list