[SR-Users] Dispatcher algorithm 11 possible priority drifting

[Володимир Іванець]

Hello Daniel,

Thank you for the explanation!

чт, 10 груд. 2020 о 15:04 Daniel-Constantin Mierla <miconda at gmail.com> пише:

> Hello,
>
> that's how the algorithm is implemented and the last one has more calls
> because it is used to fill the slots left empty because of truncation in
> percentage computation.
>
> The weight is a percentage as an integer value, practically an integer
> from 1 to 100.
>
> So, if you have 16 gateways to route to with dispatcher, each with weight
> 50, then the sum of weights is 800. The percentage corresponding to each
> gateway is computed with (50/800)*100 = 6.25, converted to integer is 6.
>
> Now, 6*16=96, so 4 slots were left empty, which are filled with the last
> destination that results in 10 slots for it.
>
> I haven't implemented the rweight algorithm, but for the weight algorithm
> is expected to set the value to an integer from 1 to 100 and have the sum
> of them to be 100, otherwise also the last gateway fills the empty slots.
> Moreover, if the sum exceeds 100, then the gateways that end up after the
> 100 slots will be ignored.
>
> Note that there are other algorithms if you want even distribution, like
> round robin or call load balancing.
>
> Cheers,
> Daniel
> On 10.12.20 12:00, Sergio Charrua wrote:
>
> I noticed the exact same behaviour with my implementation, even though the
> priority and rweight are different.
> until now, i'm ignoring the "issue". But if there is a fix, I would like
> to know too.
>
> *Sérgio Charrua*
>
>
> *www.voip.pt <http://www.voip.pt/>*
> Tel.: +351  <callto:+351+91+104+12+66>21 130 71 77
>
> Email : *sergio.charrua at voip.pt <sergio.charrua at voip.pt>*
>
> This message and any files or documents attached are strictly confidential
> or otherwise legally protected.
>
> It is intended only for the individual or entity named. If you are not the
> named addressee or have received this email in error, please inform the
> sender immediately, delete it from your system and do not copy or disclose
> it or its contents or use it for any purpose. Please also note that
> transmission cannot be guaranteed to be secure or error-free.
>
>
>
>
>
>
>
>
> On Thu, Dec 10, 2020 at 10:20 AM Володимир Іванець <
> volodyaivanets at gmail.com> wrote:
>
>> Hello all!
>>
>> We are running Kamailio version 5.3.3 with 16 small Asterisk servers.
>> Kamailio uses a dispatcher module to distribute calls. Algorithm #11 is
>> selected. All destinations are configured with priority set to 50 and
>> attribute to rweight=50.
>>
>> We noticed that one server constantly receives more calls than others. I
>> run a few tests. I was sending 1000 calls to the system. 4 per second. All
>> servers except one were getting around 60 calls while the last one - around
>> 100.
>>
>> I then noticed that the server which receives most calls is always last
>> in the "kamcmd dispatcher.list" command output. I then changed the order in
>> the dispatcher DB table and repeat the test. The other server that now was
>> last was getting the most calls.
>>
>> Does anyone else use algorithm #11 and finds the same thing? Is there
>> something additional that I can provide to help with the investigation?
>>
>> Thanks!
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/5ba437b8/attachment.htm>