<br><br><div><span class="gmail_quote">On 11/17/07, <b class="gmail_sendername">Zoa</b> <<a href="mailto:zoachien@securax.org">zoachien@securax.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>Yes, but<br>1500 calls<br>3000 call streams<br>50 pps per call stream<br>thats 150.000 pps + signalling, we need double the packets per second on<br>that machine to have that amount of calls. (sure the test is not 1500
<br>call legs?)</blockquote><div><br><br>The reported bandwidth usage would coincide with 1500 legs not calls, although sipp claims that it did just over 1500 concurrent at one point, which in theory was relayed to some other box, but that means half the media was gone - not good for business applications as your customers would freak that there is no audio on their calls. So until I get clarification on why only half the bandwidth was present on the asterisk server than what should have been I am thinking this test was not quite as valid as it could have been.
<br><br>I agree with bkw as well about 8.5 cps being really low. It doesnt matter as much if you have normal business customers, so long as you have enough of them that you exceed 8.5 cps. Yeah 1 customer or maybe even 2 would generate that much, but it depends if you are their in office machine or the ITSP servicing them. The ITSP is far more likely to see greater than
8.5 cps per box. By keeping the cps really low like that it invalidates the test to a point since call setup and tear down tend to be more expensive than pushing bits for media. By increasing the cps to 30-60 I am willing to bet that the overall capacity of the switch will be diminished. This is important since the report tried to extrapolate on what it would cost to do a given number of channels, and calls that section into question. I would like to see a new test performed that addresses many of the things that have been brought up here. That could make the results even more realistic, unless of course the results would not be favourable, then we should just bury the test and forget it happened :)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>BKW, my gut tells me that server will handle over 60 call setups per<br>second on asterisk, but not when running on nearly 100% cpu, so you can
<br>do more call setups per second in the beginning of the test, but when<br>nearing the maximum throughput of rtp, callsetups need to be less to be<br>able to complete the max throughput test.</blockquote><div><br>I agree with that, generally you will start to flood the queue and it will take forever for a new call to come up or it will just timeout. And if you have a large enough Rx queue on the server you will start to process not only the initial request but also the retrans which occured during timeout, and you see even higher load.
<br></div><br></div><br>-- <br>Trixter <a href="http://www.0xdecafbad.com">http://www.0xdecafbad.com</a> Bret McDanel<br>Belfast +44 28 9099 6461 US +1 516 687 5200<br><a href="http://www.trxtel.com">http://www.trxtel.com
</a> the phone company that pays you!