|
Dear Horms,
I'm still in slow start mode this year, too many other interesting
things to follow ... so sorry for the huge delay.
Doesn't mean that if the lower threshold isn't set, then the
number of connections needs to drop to 0 before an overloaded
real server will be marked as un-overloaded.
Correct and this is also what people would expect. The threshold
functionality in science has always worked that way, be it in
mathematics, electrical engineering, economics, or whichever field; you
name it. There is just no reason to add an artificial barrier to the
semantics of upper (UT) and lower threshold (LT). It's also wrong from a
pragmatic point of view.
While I think the simplicity of your approach makes a lot of sense.
I also think it makes a lot of sense for users to just specify
the upper threshold and have something sensible happen, which
to my mind is something like the current 3/4 rule.
I tend to disagree for the following reasons:
a) It changes the well-known and established notion of threshold
handling in science. There is absolutely no reason to have an implicit
LT of 3/4 when only an UT is set.
b) 3/4 is neither calculated (mathematically founded to be usefull
regarding a certain workload) nor did anyone ever make a reasonable
attempt to explain why this cut-off barrier was chosen. If you look at
the usage of the threshold limitation, which IMHO is to limit workload
of a RS to a well defined amount of connections _and_ then have a
relaxation time (UT) you will notice that using a fixed percentage (when
not specifying a LT) is really wrong. If you take the differential graph
dUT/dLT over the processing power of the RS and lay it next to the graph
of the response and relaxing time of the server you will notice that
they are completely not correlated.
c) You have 65537*65536/2 ways of setting a {UT,LT} tuple and for only
one specific tuple {UT, 0.75*UT} you have a special semantic and two
ways of achieving the same tuple, with 3 additional lines in the kernel.
This does not make sense. I can go on with the numbers, but it's getting
silly :). I reckon you get my point.
d) My original threshold code for 2.2.x kernels, which the 2.6.x code is
largely based on, does not contain this feature. It was never requested.
Tell me 1 single advantage of having this artificial cut-off. On a less
funny sidenote: I've spent (because I've never read that man page) 30
minutes debugging exactly this behaviour because I didn't know about it.
I went crazy when I saw that my RS did get added again to the pool, but
I took me some time to realize that it was 75% of the UT before I went
on and checked the kernel source.
Cheers,
Roberto Nibali, ratz
--
echo
'[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq' | dc
|
