Quote:
|
Originally Posted by Hodders
I've now been able to run a tcpdump on both the server and the client.
I can see the packets leaving my firewall but never arriving at the server until about 2 minutes later! The conclusion is that the FTP packets are being held up somewhere on the way.
|
tcpdump only shows the user data that is sent or received: it does not show the protocol traffic on the wire, and the TCP recoveries and retransmissions in the event of failure.
A possible explanation of your observed "delay" is that there was no delay in NTL at all, but that a TCP packet was lost on the way from your FTP client to the remote server, or the TCP ACKs from the far end never made it back to your FTP client, so your FTP client sat there timing out and retransmitting the TCP packet until eventually it got through. An ethernet sniffer on the wire between your NAT router and the cable modem would reveal all.
A possible cause of packet loss might lie within your own network if, for instance, you have an ethernet duplex mismatch on any link. The best duplex setting depends on what model of cable modem you have.
Other causes are known to be Pace digital TV set top boxes (if that is what your cable modem is), if they are pushed anywhere near the upstream rate cap (as FTP uploads tend to do). You might get better upstream throughput by rate-limiting your aggregate upstream demand to be about 80% to 85% of the nominal upstream rate cap for your cable account. Then the STB will never get stressed anywhere near the upstream rate cap.