Date: Thu, 21 Nov 2002 16:26:56 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: "David G. Andersen" <danderse@cs.utah.edu>, hackers@freebsd.org Subject: Re: Changing socket buffer timeout to a u_long? Message-ID: <3DDD79D0.888A1A39@mindspring.com> References: <Pine.BSF.4.21.0211211200420.4708-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > On Thu, 21 Nov 2002, David G. Andersen wrote: > > Are there compelling reasons not to change the socket buffer > > timeout to a u_long from a u_short? This variable stores > > the number of ticks before the socket operation times out. > > > > At present, the maximum SO_RCVTIMEO or SO_SNDTIMEO value one > > can set is SHRT_MAX / hz. With a 100Hz kernel, this comes > > to about 330 seconds, but with a 1000Hz kernel or faster, > > it's reduced to under 1 minute, which tends to break some > > apps when running on a high-hz kernel. > > > > Particularly for weirdos who use HZ=10000 for dummynet purposes > > and network measurement, increasing the storage to a u_long > > would make life a bit happier for all sorts of code that wants > > to set a 1 minute timeout. > > I can see this in -current. > In -stable I'm not sure of the ramifications. It might screw up any > proprietary loadable protocols. I Think there are a couple of them. A bigger sockaddr_in means fewer of them in the same amount of memory means fewer total connections per machine for a given set of resources. Personally, I think these timers are all set length, and that means (to me) that a length-list is the way to go (prior art back to 1978 or so). If you don't want to do that, then the next best thing is to keep the count in terms of MSL, instead of in terms of ticks. Note that it's reasonable, for high speed connections, to reduce the MSL proprotionally to the data rate. FWIW: upping the roll-over rate is not a good reason to increase the size of fields, unless you want to increase the TCP sequence number filed to 64 bits? ...it has exactly the same issues at high data rates. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DDD79D0.888A1A39>