|
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)
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 :-).
> 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.
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
|
