Date: Tue, 23 May 2006 11:17:22 -0400 From: Bill Vermillion <bv@wjv.com> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-net@freebsd.org, mag@intron.ac Subject: Re: How to Quicken TCP Re-transmission? Message-ID: <20060523151722.GF26739@wjv.com> In-Reply-To: <20060522130648.GB33204@uk.tiscali.com> References: <20060522115722.15918F1590@smtp.263.net> <20060522130648.GB33204@uk.tiscali.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Bits dont fail me now!" was what Brian Candler muttered as he hastily typed this on Mon, May 22, 2006 at 14:06 : > On Mon, May 22, 2006 at 07:51:33PM +0800, mag@intron.ac wrote: > > I want to transmit data between host A and host B. The link between > > these two hosts is really bad: PING reports 30% packet loss > How big are the pings? Try > ping -c100 -s1472 x.x.x.x > > to send 1500-byte pings (20 bytes IP header + 8 bytes ICMP > header + 1472 bytes padding). This will give you a more > realistic indication of packet loss for TCP transfers than the > small pings you get by default. The original poster noted that he had used -s1472 in his tests. I had the same exact problem one time as the OP did. Regular pings would go through, data throughput was terrrible and going with every larger packet sizes I found things really fell apart about 500 byte sizes. In my case it was a bad card in a Cisco 12000 switch at the local Level 3 facility where my servers were. There were only about 6 other clients on that card, and since I made the call about 6AM I was the first to notify them. IOW - while your problem may indeed be somewhere in the link don't discount the fact that the problem could be much closer. Have you tried a traceroute to see if it is at one particular link. If your provider does not block it you might try the -R option to ping the site to help pinpoint the source of the problem. Bill -- Bill Vermillion - bv @ wjv . com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060523151722.GF26739>