[PATCH] wlib scheduler (fwd)

[Wensong Zhang]

Hi,

On Mon, 17 Jan 2005, Chris Caputo wrote:

> Hi.  I pondered doing a multiply like in the other schedulers but decided
> against it due to 32-bit overflow likelyhood, ex:
>
>    (weight of 65535) * (inbps > 65535)
>

Yes, it's likely.

> If doing a 64-bit based multiply is okay I could convert the code to use
> that.  I agree the accuracy would be better for low bitrates.  Please let
> me know if I should revise in this manner and I'll do so (along with the
> name change :-).
>

Yes, please do it, 64-bit based multiply is fine.

>> BTW, have you used this schedule in any real applications?
>
> Yes, it is being used to balance and provide failover for incoming
> newsfeeds at my site.  (about 200 Mbps continuous across two DR directors)
> I've tested the startup round robin aspect in this scenario too.
>

Cool, 200 Mbps is a big incoming traffic.

Thanks,

Wensong

> By the way, the LVS code is a joy to work with.  My sincere thanks to you
> and everyone else who has contributed.
>
> Chris
>
> On Tue, 18 Jan 2005, Wensong Zhang wrote:
>> Hi Chris,
>>
>> Yup, maybe "Weighted Least Incoming Bps" is a better name. :)
>>
>> The comparison based on integer division is not accurate because is
>> ignored, and the expense of division operation is more expensive than
>> multiply operation. Maybe we can convert the comparison in the following
>> way:
>>
>>  	int inbps;
>>  	int least_inbps;
>>
>>  	...
>>
>>  	spin_lock(&dest->stats.lock);
>>  	inbps = dest->stats.inbps;
>>  	spin_unlock(&dest->stats.lock);
>>
>>  	if (least == NULL ||
>>  	    (inbps * atomic_read(&least->weight)
>>  	     < least_inbps * atomic_read(&dest->weight)) {
>>  		least = dest;
>>  		least_inbps = inbps;
>>  	}
>>
>> BTW, have you used this schedule in any real applications?
>>
>> Thanks,
>>
>> Wensong
>>
>> On Sun, 16 Jan 2005, Chris Caputo wrote:
>>
>>> Hi.  Would "Weighted Least Incoming Bps" be a better name?
>>>
>>> I am not sure how the byte rate and packet rate could be combined
>>> together.  Would you like to see a compile time configuration hook that
>>> determines which one is used?
>>>
>>> I believe the divide that is done in the code is okay in the kernel since
>>> it is integer based rather than float based.
>>>
>>> Thanks,
>>> Chris
>>>
>>> On Mon, 17 Jan 2005, Wensong Zhang wrote:
>>>> On Fri, 14 Jan 2005, Julian Anastasov wrote:
>>>>> On Thu, 13 Jan 2005, Chris Caputo wrote:
>>>>>> Please consider the below patches against ipvsadm-1.24 and linux kernel
>>>>>> 2.6.10 which add a "Weighted Least Incoming Bandwidth" scheduler to LVS.
>>>>>>
>>>>>> I have also put these up at:
>>>>>>
>>>>>>   http://www.caputo.com/foss/ipvsadm-1.24-wlib.patch
>>>>>>   http://www.caputo.com/foss/lvs_wlib-2.6.10.patch
>>>>>>
>>>>>> Comments and suggestions welcome.  I'd like to work towards this being
>>>>>> included in future releases if you think it worthwhile.
>>>>>
>>>>> 	It looks good to me. Balancing based on outbps can
>>>>> also be a good option for NAT. I assume there is one side effect,
>>>>> one server can accept more load in short time while its inbps are
>>>>> still low. As alternative, a wrr algorithm with weights updated
>>>>> (frequently enough) based on inbps/outbps can better keep the
>>>>> load according to the weights. But it depends on the content length per
>>>>> connection, on the estimator's update period (isn't 2 seconds too
>>>>> high for wlib) and only the traffic stats can make one happy :)
>>>>>
>>>>
>>>> Agreed.
>>>>
>>>> As for "Bandwidth" in the name of this scheduler, shall we consider to
>>>> combine byte rate and packet rate together? different applications may
>>>> require different caculating method. we probably need to have some
>>>> flexibility in configuration.
>>>>
>>>> BTW, there is probably no float in kernel mode, it's good to transform
>>>> the comparison formula.
>>>>
>>>> Thanks,
>>>>
>>>> Wensong
>