10 Dec
2020
10 Dec
'20
5:17 a.m.
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!
10 Dec
10 Dec
6 a.m.
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(a)voip.pt <sergio.charrua(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
8:02 a.m.
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(a)voip.pt <mailto:sergio.charrua@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(a)gmail.com <mailto:volodyaivanets@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(a)lists.kamailio.org <mailto:sr-users@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(a)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
11:02 a.m.
Hello Daniel,
Thank you for the explanation!
чт, 10 груд. 2020 о 15:04 Daniel-Constantin Mierla <miconda(a)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(a)voip.pt <sergio.charrua(a)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(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
1233
days inactive
1233
days old
3 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Sergio Charrua -
Володимир Іванець