[SR-Users] Dispatcher algorithm 11 possible priority drifting

Daniel-Constantin Mierla miconda at gmail.com
Thu Dec 10 14:02:00 CET 2020


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 <mailto: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 <mailto: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 <mailto:sr-users at lists.kamailio.org>
>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>     <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201210/703c02b4/attachment.htm>


More information about the sr-users mailing list