Date: Fri, 13 Jul 2001 17:47:25 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: Leo Bicknell <bicknell@ufp.org> Cc: Matt Dillon <dillon@earth.backplane.com>, Drew Eckhardt <drew@PoohSticks.ORG>, hackers@FreeBSD.ORG Subject: Re: Network performance tuning. Message-ID: <Pine.LNX.4.20.0107131734170.11432-100000@www.everquick.net> In-Reply-To: <20010713132903.A21847@ussenterprise.ufp.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 13 Jul 2001 13:29:03 -0400 > From: Leo Bicknell <bicknell@ufp.org> (The window autotuning was an interesting read...) > I think you're doing good work, but I'm concerned you're going > down a road that's going to take a very long time to get right. > It is not necessary to calculate the bandwidth*delay in order to > prevent over-buffering. Preventing overbuffering only requires > tracking the maximum bandwidth*delay value, assuming that we > always want the ability to buffer that much data. I think the > number of cases where it decreases significantly over the peak > for a long enough time to make a difference is minimal. This sort of reminds me of semi-empirical vs. ab initio molecular modeling in Chemistry. MOPAC is great for quick calculations with fairly loose tolerances; a good semi-empirical calculation is better than a crude ab initio. However, for super-high precision, lengthy ab initio calculations in Gaussian are the rule. Being a realtime application, I'd presume that empirical methods are better for this sort of work. Jitter would also screw up the bw*del values. > Fully knowing the value over time could lead to optimizations > like shrinking the buffers, or attempting to prevent some > packet loss by not over-increasing the window. However > oscellation and other issues I think are going to make this > very complex. I'd imagine that dynamic buffer sizing (high water / low water) would make more sense. For new connections, we could pull from a cache of memoized, empirically-determined window sizes keyed by subnet* or IP, a la ARP- or route-caching. * The implementation would be ugly and imprecise, but a userspace daemon to give hints based on BGP or OSPF tables might be interesting. Probably impractical, but I'm just brainstorming. I'd imagine that it would make more sense to find a subnet that includes two IPs with similar window sizes, and aggregate them automatically. Perhaps do this on the insert. As for preventing oscillation, one can use moving averages and still stick with integer math if needed for x86 performance. Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked. 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?Pine.LNX.4.20.0107131734170.11432-100000>