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.)