Date: Wed, 17 Jul 2002 19:15:11 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Matt Dillon <dillon@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, <cvs-all@FreeBSD.org> Subject: Re: cvs commit: src/sys/netinet tcp_timer.h Message-ID: <20020717190935.I83269-100000@patrocles.silby.com> In-Reply-To: <20020717185653.C82638-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Jul 2002, Mike Silbersack wrote: > On Wed, 17 Jul 2002, Matt Dillon wrote: > > > dillon 2002/07/17 16:32:04 PDT > > > > Modified files: > > sys/netinet tcp_timer.h > > Log: > > I don't know how the minimum retransmit timeout managed to get set to > > one second but it badly breaks throughput on networks with minor packet > > loss. > > 1 second is an accepted minimum for retransmit timeouts. Please back this > out, and go find out why fast retransmits aren't handling minor packet > loss. > > Mike "Silby" Silbersack Let me explain myself better here: 1. The value should be scaled by hz so that it does not change with HZ settings. (That's not central the problem, though.) 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. 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. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020717190935.I83269-100000>