Date: Wed, 7 Jul 1999 18:47:05 -0500 (CDT) From: Mohit Aron <aron@cs.rice.edu> To: dg@root.com Cc: freebsd-net@freebsd.org, druschel@cs.rice.edu (Peter Druschel) Subject: Re: paper on improving webserver performance Message-ID: <199907072347.SAA23986@cs.rice.edu> In-Reply-To: <199907072300.QAA23652@implode.root.com> from "David Greenman" at Jul 7, 99 04:00:10 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I've quicky skimmed through the paper and it does appear to be well thought > out. We've known about the scalability issues with the tcp timers and large > numbers of connections for several years and I've been testing some > experimental code from Garrett Wollman which completely fixes that. The > other issue about the RTT estimator is a bit contraversial, however, as some > believe that you have to have a 1/2 second minimum regardless due to delayed > acks from the peer (and apparantly the TCP spec specifies 1/2 second rather > than the 1/5 second that Berkeley derived stacks use). This doesn't mean that > one shouldn't be accurate beyond that, however. > > -DG > > David Greenman > Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org > Creator of high-performance Internet servers - http://www.terasolutions.com Right. I do observe in a footnote that the minimum should be 200ms though I wasn't aware that the specs want this to be 500ms. In any case, having a minimum of 500ms would still be better than the 2-3s timeouts that happen sometimes. BTW, you can even get away with the 200ms (or 500ms) minimum. For example, if you have a large enough number of packets in the network (more than 2 should be enough), then you can argue that the ACKs won't be delayed as the receivers usually send an ACK every 2 or 3 packets. Then you don't have to put a minimum bound on the timeout. - Mohit 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?199907072347.SAA23986>