Hello Daniel, Thank you for the explanation!
чт, 10 груд. 2020 о 15:04 Daniel-Constantin Mierla <[email protected]> пише: > 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 : *[email protected] <[email protected]>* > > 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 Володимир Іванець < > [email protected]> 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 >> [email protected] >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> > > _______________________________________________ > Kamailio (SER) - Users Mailing > [email protected]https://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 > [email protected] > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
