Date: Wed, 17 Jul 2002 18:06:13 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Silbersack <silby@silby.com> Cc: cvs-committers@FreeBSD.ORG, <cvs-all@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/netinet tcp_timer.h Message-ID: <200207180106.g6I16Dqd004375@apollo.backplane.com> References: <20020717190935.I83269-100000@patrocles.silby.com>
index | next in thread | previous in thread | raw e-mail
:
:1. The value should be scaled by hz so that it does not change with HZ
:settings. (That's not central the problem, though.)
The value should be scaled for algorithmic stability. It should not
be set at a particular latency because then you are making some
severe assumptions in regards not only to the network latency and
bandwidth, but also in regards to the type of applications running
over it.
I have one person who is running filesystem-like transactional code
over the network. One second of latency screws things up in a major
way for him.
:2. 3 ticks * 10ms should = 30ms. Even on a nice ethernet network, I
:think that's a bit low of a retransmit timeout; a simple router hiccup
:could cause a bunch of needless retransmits.
The retransmit timeout is a calculation based on the exponentially
averaged RTT. The minimum is just that... a minimum. If the
calculation winds up being 1 ms then that is what the retransmit
timeout should be.
On a gigabit network a 1 second retransmission timeout is simply
absurd. Period.
:I don't doubt that changing this value may show improvements in _some_
:environments, but it's probably not a good idea to allow retransmit
:timeouts this small in regular practice.
Why not?
:What do the traceroutes you gathered look like? Are these bulk transfers
:being hung up by something broken in our fast retransmit mechanism, or are
:you watching telnet-ish stop and go connections?
:
:I'm not saying that the minimum of 1 second can't be changed... 500ms
:might be reasonable. However, 30ms seems really too short.
:
:Mike "Silby" Silbersack
I'm watching traffic over a 100BaseTX switch and using dummynet to
simulate packet loss. Go ahead and try it yourself... just 1%
packet loss screws everything up with the minimum latency set to
one second. Try doing a large ftp transfer. Then reduce the minimum
latency so it doesn't interfere with the normal retransmission mechanisms
and try doing the large ftp transfer with 1% packet loss again. BIG
difference.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207180106.g6I16Dqd004375>