> Date: Fri, 13 Jul 2001 13:29:03 -0400
> From: Leo Bicknell <[EMAIL PROTECTED]>
(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 <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>, or you are likely to be blocked.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
