Sorry for the delay in response
On Sat, 2002-09-28 at 04:36, Dworf wrote:
> And the last one... about the route cache can i reduce the timeout in chache
> from default 60s i think to lets say 1 and that when new connections are made
> they are more frequently reorganized over the load balance?
Now I am no guru but I will try to explain the following based on my
observations while spending about a week playing around with different
values. I was trying to load balance two SDSL lines, and when I finally
used Julian's patches and got everything working. I reverted back to the
default values for the route cache. So whether you really need to adjust
this is a mood issue. I did not find it a necessity.
I will go in order and below are the values I last tested, and the
default values.
# Default Values
#echo 256 > /proc/sys/net/ipv4/route/gc_elasticity # 8
#echo 1 > /proc/sys/net/ipv4/route/gc_interval # 60
#echo 0 > /proc/sys/net/ipv4/route/gc_timeout # 300
#echo 0 > /proc/sys/net/ipv4/route/gc_min_interval # 5
#echo 128 > /proc/sys/net/ipv4/route/gc_thresh # 256
#echo 1 > /proc/sys/net/ipv4/route/max_delay # 10
#echo 1 > /proc/sys/net/ipv4/route/min_delay # 2
#echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter # 1
#echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter # 1
I also looked at the code behind this in route.c, but it did not make
much sense. I may look at it again some other time. Now I find it funny
that the above entries in the /proc file system have little description
or explanation. I cam across very few docs on them, and most were very
incomplete. Not that my observations are any better.
Now the gc_elasticity seems to have something to do with the # of routes
that are expired/removed as part of the gc. A lower # means more gc's to
clear out the cache. A higher # means more at a time.
The gc_interval is pretty self explanatory. However setting this to low,
like 1 causes route lookups to occur more often, and can impact
performance. So be careful with using low values, and stay away from 1.
The gc_timeout seems to be a timeout between gc's?
The gc_min_interval is the minimum interval between gc's?
The gc_thresh hold I believe is the # of routes that can be in cache at
any one time. Not to sure, but it does seem to have an effect, and is
relative to the gc_elasticity. I usually would adjust both.
The max_delay is some sort of max delay in between gc's?
The min_delay is some sort of minimum delay in between gc's?
Basically there is an algorithm that uses all the above values together
to maintain good performance on most machines out there. I assume they
are adjustable for dialing into the machine for specific tasks. It's
hard to say just adjust one. Since each has an effect on the other,
usually you have to adjust most if not all to see a difference.
When all was said and done for me, despite all the experimenting and
testing, I went back to using the default values. When I was able to
make a noticeable adjustment, that seemed to work, it later had other
effects as the load changed.
So that's my .02 base on my experiences. I welcome other to comment, so
maybe we can get some documentation on the web as to what each value
actually does.
--
Sincerely,
William L. Thomson Jr.
Support Group
Obsidian-Studios Inc.
439 Amber Way
Petaluma, Ca. 94952
Phone 707.766.9509
Fax 707.766.8989
http://www.obsidian-studios.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
