Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Gregory Boehnlein
> Ultimately a standard test suite like the one so helpfully > published in this thread would benchmark the baseline config, then the transcoding > config, as this one did. But for each of the combinations of the > various codecs. Then a benchmark adding each of various options, like > confer

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Trixter aka Bret McDanel
On 11/17/07, Matthew Rubenstein <[EMAIL PROTECTED]> wrote: > > Ultimately a standard test suite like the one so helpfully > published in > this thread would benchmark the baseline config, then the transcoding > config, as this one did. But for each of the combinations of the various > codec

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Trixter aka Bret McDanel
On 11/17/07, Talking Voice <[EMAIL PROTECTED]> wrote: > > Have you seen the stats on rtpproxy http://www.rtpproxy.org it seems > to be far more impressive than those of Asterisk B2BUA. it also does less work. It does not relay media, and those numbers arent impressive when you consider there ar

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Matthew Rubenstein
Ultimately a standard test suite like the one so helpfully published in this thread would benchmark the baseline config, then the transcoding config, as this one did. But for each of the combinations of the various codecs. Then a benchmark adding each of various options, like conferencing,

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Chris Bagnall
> Asterisk was running on a server with two Xeon 5140, dual core, 2.33 GHz > CPUs and 4 GB of RAM. > We found that an Asterisk B2BUA on this hardware can manage 1500 > simultaneous calls with no transcoding and 400 simultaneous calls with G.711 > to G.729 transcoding. Many thanks for the testing d

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Brian West
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 re

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Talking Voice
Have you seen the stats on rtpproxy http://www.rtpproxy.org it seems to be far more impressive than those of Asterisk B2BUA. On Nov 16, 2007 3:02 PM, Jim Dalton <[EMAIL PROTECTED]> wrote: > We recently performed an indepth performance test on Asterisk V1.4.11 > configured as a SIP B2BUA. > > Ast

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Trixter aka Bret McDanel
On 11/17/07, Zoa <[EMAIL PROTECTED]> wrote: > > > > Yes, but > 1500 calls > 3000 call streams > 50 pps per call stream > thats 150.000 pps + signalling, we need double the packets per second on > that machine to have that amount of calls. (sure the test is not 1500 > call legs?) The reported ban

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Zoa
Yes, but 1500 calls 3000 call streams 50 pps per call stream thats 150.000 pps + signalling, we need double the packets per second on that machine to have that amount of calls. (sure the test is not 1500 call legs?) Yes, linux can do that in the kernel on that machine, the intel e1000 networ

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Lenz
Well done. I posted the news to AstPligg as well: http://tinyurl.com/yntzhy Thanks l. On Fri, 16 Nov 2007 21:02:07 +0100, Jim Dalton <[EMAIL PROTECTED]> wrote: > We recently performed an indepth performance test on Asterisk V1.4.11 > configured as a SIP B2BUA. > > Asterisk was running on a

Re: [asterisk-biz] Asterisk Performance Results

2007-11-17 Thread Alistair Cunningham
Zoa wrote: > It is not because they cannot test more than 5000 simultaneous calls in > their lab, that by using openser they can't scale more. > openser is known to handle more than people can throw at it (especially > if you dont care about the packets per second and run it stateless, it > will