Date: Sun, 22 Dec 2002 22:52:35 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "matthew c. mead" <mmead@goof.com> Cc: Robert Watson <rwatson@FreeBSD.ORG>, freebsd-net@FreeBSD.ORG Subject: Re: TCP interactions (was: Re: Linux and FreeBSD poor network performance) Message-ID: <200212230652.gBN6qZmI035236@apollo.backplane.com> References: <20021221165745.A67089@goof.com> <Pine.NEB.3.96L.1021222105809.91887B-100000@fledge.watson.org> <20021222151259.A21189@goof.com> <200212222106.gBML6INI032302@apollo.backplane.com> <20021222230527.A30324@goof.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
:Hmm, same cables, same switch, different card, now it all works.
:
:I did do some ICMP ping testing with ping -f and only lost 3
:packets after letting it run for a good 10s.
:
:
:-matt
If it is working properly you should not lose *ANY* packets on an
otherwise idle connection, except possibly the last one that the
ping was sending when you ^C'd it (and sometimes ping doesn't wait
long enough on the last packet when you give it a specific count).
So at most it should report one lost packet over any period of time.
Certainly not 3.
e.g.
workstation# ping -c 1000 -i 0.05 apollo
...
1000 packets transmitted, 1000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.148/0.159/0.248/0.009 ms
If you think about it, 3 lost packets in 10 seconds is one lost packet
every 3 seconds or so. That could have an adverse effect on tcp
throughput depending on whether NewReno/fast-retransmit is working or
not. But even with all the algorithms working properly packet loss
can slow TCP down.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212230652.gBN6qZmI035236>