23/11/2004: App_Playback part 2.
We discovered that when while testing asterisk during the playback test,
we forgot to look if all calls originated by our application were also being executed by asterisk.
This means we will have to review the test results, new measurements are:
540 when the clients not sending/playing any audio frames back to the media server.
310 when the clients are sending/playing audio frames back to the media server.
The difference in these results makes us to think that the network card / driver / operating system might be of huge importance for the results.
We will retry the tests on FreeBSD and with another networkcard.
(as the BSD people seem claim a 10 times higher throughput (pps) for small packets.)
22/11/2004: Music On Hold Part 1.
Today we reached 361 simultaneous SIP uLAW Music On Hold channels on that same 350$ machine.
When using GSM we got up to 173.
Out of curiosity we tried some optimized configs with anthm's music on hold native format patch and got to 395 channels, regardless of the codec used.
We are currently investigating more ways of increasing that value. (As we think it should scale higher than app_playback).
20/11/2004: Asterisk Makes a great media server.
Today, we were able to reach an astonishing 790 simultaneous audio playbacks. (sip to asterisk, any codec.) on a 350$ pc.
Tests were done on we a pIV on 2.4ghz with 512mb ram.
Small sidenote: we found the statement in the presentation claiming you should never go under 50% idle cycles to be wrong.
We should add "unless you dont do cpu hungry tasks such as transcoding." as we went as low as 1% idle cpu cycles without the slightest audio glitch in this test.
14/11/2004: ADPCM optimizations.
Today, some performance tweaks made it into asterisk-CVS. (thnx to fOSSiL)
Checkout bug report 0002853 on mantis.
Please note the NOT_BLI option you have to enable in codec_adpcm.c !
Graphs coming soon.
|