On 2012 Feb 16, Thu 14:17:38 you wrote: > o Robert Szokovacs on 02/16/2012 02:01 PM: > > Hi, > > > > While tuning our SEMS-based application, we noticed that receiving RTP > > significantly lowers the number of concurrent sessions with acceptable > > audio quality (we achieved around 1800 concurrent sessions on a 4-core > > machine). > that seems to be pretty few. Are all cores then fully loaded, or do > you experience higher jitter or delay already earlier (i.e. lock > contention; CPU still at low usage, but queues filling up etc).
We used 3 media threads, and the load was around 300%. The 1800 was with low jitter. We did not really push higher, because we were testing with the default MAX_RTP_SESSIONS=2048. (Any particular reason for that value?) > > what codec are you using? how many media processing threads? PCMA codec. > You may also check out the multi RTP receiver threads introduced more > recently, and there were more performance related changes more > recently (your patch looks like to some 1.4 version). We will test those once 1.5 is out :) [...] > > Is there any drawbacks to this approach? > > I don't see any, if you don't need the audio, or in-band DTMF. The > DTMF event queue of the session is protected by its mutex, so it's > safe to post events there from the RTP receiver threads the same way > as the media processing thread. You have your sessions in the > MediaProcessor, I guess, so DTMF should be processed and passed to the > applicaiton. So, shall I submit a proposed patch then? br Szo _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
