|
>> Actually according to the URL below, alive connections Ci for each
>> server i is always 1 or more in WLC scheduling. Therefore I
>assume the
>
>I read the document of LVS scheduling algorithms again, there
>is no such
>assumption that the alive connection number for each server is
>always 1 or
>more in the WLC.
>
>In the implementation, the number of connections per each
>server can be
>any value in the interval of [0, 2^32].
>
Hi,
You are absolutely right. I managed to read one part of that page wrong
several times.
So, WLC does not include the incoming job for its cost function. Now I
must ask why this design choice came to be? After all, what is
calculated is an estimation of response time for that job. But the WLC
cost function calculates the value from system state before the
allocation of the job, not after which of course is what really matters.
This is why the classic SED policy I described earlier has the increment
of 1 in the cost function.
Consider this example: a server with W1=2 and a server twice as fast
with W2=4. The former has C1=1 and the latter C2=2. So WLC cost function
returns 0.5 for both servers, as if both were as good choices. An
additional comparison of W is needed to determine which server actually
is a better selection. I don't know if the implementation of WLC does
this comparison or selects either one randomly?
The SED cost function however immediately returns 1 for the former and
0.75 for the latter server and thus describes better the states after
the job would be located on these servers. One would imagine that
implementation of latter algorithm would be more efficient because it
seems to come down to an addition vs. a comparison loop.
Also consider this example: two servers with jobs/weight of 1/1 and
11/10. WLC policy will select the former server. SED policy sees it as
2/1 = 2.0 vs. 12/10 = 1.2 thus the latter is chosen while it is expected
to produce better response time for the job.
If WLC would adopt cost function like SED, then the I would recommend NQ
policy modification to be added as well.
Regards,
Marko
|
