[SR-Users] RTPProxy

[Daniel-Constantin Mierla]

Hello,

thanks for all those details, very useful ...

To be clear -- the issue of using high cpu on idle (no active calls) was
with rtpproxy v1.2 on a centos (iirc, v6), not with rtpproxy 2.0. On
debian, same version of rtpproxy was not exposing this. I was just
curios to see if anyone else saw it ... might have been just that system...

Cheers,
Daniel


On 19/10/16 20:00, Maxim Sobolev wrote:
> Just a little comment on the numbers that I've thrown out earlier
> today. Those are probably somewhat pessimistic, with some creative
> tuneup you can probably go much higher. But we also constrained by
> some other considerations (i.e. running fully redundant network
> connection with FEC, full firewall etc, custom OS), so those are what
> we get.
>
> Also, I wanted to point to the list, speaking about number of sessions
> is pretty much pointless, as the main thing that keeps us busy is
> packet per second rate. Since same 10,000 sessions might translate to
> as much as half of PPS rate if use 10ms ptype versus 20ms ptype. Our
> limit at this point of time is some 450k PPS in and 450k PPS out, 16
> cores, FreeBSD 10.3, which could be either 4.5k sessions with 10ms
> packets or 9k sessions with 20ms or somewhere in between if you have
> mixed traffic (as most of our customers do). Latest Linux kernels
> might get better contention control on higher CPU count systems, or at
> least it is what I've seen on some of the benchmarks not so long time
> ago, We've planned to run some evaluations but have not got time to do
> so yet.
>
> On top of that, even if you can push say 1 million PPS through single
> tuned up box (10k sessions at 10ms), some other constrains may arise.
> Most of the general-purpose DC providers we've encountered in our
> somewhat limited practice, design their networks with much lower PPS
> per port in mind. It's often an issue with a new DC here that we bump
> into all sorts of automated DDoS prevention systems once we reach
> 100-200k PPS per box/port. So at the end of the day it might be more
> practical and economical to run bunch of the smaller nodes and spread
> the load across them using something like rtp_cluster rather than try
> to cram all that traffic into a single box/port.
>
> -Max

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20161020/213ab615/attachment.html>