Here are the tests I would like to see. 10-30cps, variable aloc (1ms lowest/10ms max)
The issue is if Asterisk is public facing it takes a burst of 10-15 calls at once can cause issues. So Asterisk MUST survive these kinds of things even if you don't feel they are real world examples. To really find issues you need very short aloc because call setup and tear down is where race conditions are exposed. /b On Nov 17, 2007, at 7:22 AM, Trixter aka Bret McDanel wrote: > > 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. > > 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 :) > > > BKW, my gut tells me that server will handle over 60 call setups per > second on asterisk, but not when running on nearly 100% cpu, so you > can > do more call setups per second in the beginning of the test, but when > nearing the maximum throughput of rtp, callsetups need to be less to > be > able to complete the max throughput test. > > 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. > > > -- > Trixter http://www.0xdecafbad.com Bret McDanel > Belfast +44 28 9099 6461 US +1 516 687 5200 > http://www.trxtel.com the phone company that pays you! > _______________________________________________ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-biz mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-biz _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
