Matthew J. Roth wrote:
> In the meantime, I'm looking for insights as to what would cause
> Asterisk (or any other process) to idle at the same value, despite
> having similar workloads and twice as many CPUs available to it. I'll
> be working on benchmarking Asterisk from very low to very high
On 01/06/07, Matthew J. Roth <[EMAIL PROTECTED]> wrote:
Mon Apr 2 12:15:01 EDT 2007
Idle (sar -P ALL 60 14) (60 seconds 14 slices)
Linux 2.6.12-1.1376_FC3smp (4core.imminc.com) 04/02/07
12:24:01 CPU %user %nice %system %iowait %idle
12:25:02 a
John Hughes wrote:
Matthew J. Roth wrote:
As far as Asterisk is concerned, at low call volumes the dual-core
server outperforms the single-core server at a similar rate.
Outperforms in what sense?
At low call volumes the cumulative CPU utilization, expressed as a
percentage of avail
Hi Matthew:
Your environment sounds quite challenging and I'd be interested in the
analysis of what is limiting the throughput.
I agree that there's no easy way to distribute and single queue across
multiple boxes.
But here is a scaling idea for you. We've used it successfully to
handle a larg
John Hughes wrote:
For me all these numbers look too small to be useful for benchmarking.
John,
They are small, and they are probably more useful as baseline numbers.
I'm working on writing up some data I've collected off of our production
switch. The call range is 0-450 at 10 call increment
John Hughes wrote:
OpenSSI can't (at the moment) migrate threads between compute nodes. It
can migrate separate processes, but doesn't Asterisk use threads?
John,
Asterisk uses 1 thread per call, plus about 10 to 15 background threads
that persist throughout the life of the process.
I'm cur
Matthew J. Roth wrote:
> This post contains the benchmarks for Asterisk at low call volumes on
> similar single and dual-core servers. I'd appreciate it greatly if
> you took the time to read and comment on it.
For me all these numbers look too small to be useful for benchmarking.
___
Matthew J. Roth wrote:
> Recently, we were pushing our server to almost full CPU utilization.
> Since we've observed that Asterisk is CPU bound, we upgraded our
> server from a PowerEdge 6850 with four single-core Intel Xeon CPUs
> running at 3.16GHz, to a PowerEdge 6850 with 4 dual-core Intel Xeo
Sean M. Pappalardo wrote:
> Hi there.
>
> Just curious if you've checked out Linux clustering software such as
> OpenSSI ( http://www.openssi.org/ ) and run Asterisk on it? It
> features a multi-threaded cluster-aware shell (and custom kernel) that
> will automatically cluster-ize any regular Linux
FYI,
http://www.voip-info.org/wiki/index.php?page=Asterisk+FAQ
*Can i install Asterisk on a beowulf cluster?* A cluster can't migrate
threads that use shared memory. Asterisk uses that kind of threads.So no,
Asterisk wouldn't work on a cluster. *(It might be helpful to know whether
anyone has a
Mark Coccimiglio wrote:
Sounds like you are running into the hardware limitations of your
systems PCI or "Front Side Bus" (FSB) and not necessarily an issue of
asterisk. In short there is a limited amount of bandwidth on the
computer's PCI Bus (33 MHz) and the FSB (100-800MHz). One thing to
William Moore wrote:
Are you recording memory figures as well and have you checked the
total used memory? Or did I miss it somewhere? Thanks for doing
this, scalability testing is always good.
William,
This round of benchmarking is heavily focused on CPU utilization,
because it is causing an
Luki wrote:
Perhaps a naive question, but how does 0.137% CPU utilization per call
equal 1735 MHz per call?
If 1735 MHz / 0.137% = 1735 MHz / 0.00137 => 1266423 MHz at 100%
utilization ??! Even with 4 CPUs, those would be 316 GHz CPUs.
I think you meant:
Average CPU utilization per call: 0.137%
Average CPU utilization per call: 0.137% (~1735 MHz)
Perhaps a naive question, but how does 0.137% CPU utilization per call
equal 1735 MHz per call?
If 1735 MHz / 0.137% = 1735 MHz / 0.00137 => 1266423 MHz at 100%
utilization ??! Even with 4 CPUs, those would be 316 GHz CPUs.
I think you meant
On Saturday 26 May 2007 1:21 am, Edgar Guadamuz wrote:
> Very good... by the way, I'm studing electrical engineering and I've
> chosen asterisk scalation as my final graduation project. I hope do a
> similar work within and asterisk cluster.
I've been working as an EE, and I've got to ask... what
Matthew J. Roth wrote:
In fact, it seems that somewhere between 200 and 300 calls, the two
servers start to exhibit similar idle times despite one of them having
twice as many cores.
Sounds like you are running into the hardware limitations of your
systems PCI or "Front Side Bus" (FSB) a
Very good... by the way, I'm studing electrical engineering and I've
chosen asterisk scalation as my final graduation project. I hope do a
similar work within and asterisk cluster.
On 5/25/07, William Moore <[EMAIL PROTECTED]> wrote:
On 5/25/07, Matthew J. Roth <[EMAIL PROTECTED]> wrote:
> Li
On 5/25/07, Matthew J. Roth <[EMAIL PROTECTED]> wrote:
List users,
This post contains the benchmarks for Asterisk at low call volumes on
similar single and dual-core servers. I'd appreciate it greatly if you
took the time to read and comment on it.
Are you recording memory figures as well and
Sean M. Pappalardo wrote:
Just curious if you've checked out Linux clustering software such as
OpenSSI ( http://www.openssi.org/ ) and run Asterisk on it? It
features a multi-threaded cluster-aware shell (and custom kernel) that
will automatically cluster-ize any regular Linux executable (such
List users,
This post contains the benchmarks for Asterisk at low call volumes on
similar single and dual-core servers. I'd appreciate it greatly if you
took the time to read and comment on it.
Thank you,
Matthew Roth
InterMedia Marketing Solutions
Software Engineer and Systems Developer
Hi there.
Just curious if you've checked out Linux clustering software such as
OpenSSI ( http://www.openssi.org/ ) and run Asterisk on it? It features
a multi-threaded cluster-aware shell (and custom kernel) that will
automatically cluster-ize any regular Linux executable (such as the main
As
List users,
Using Asterisk in an inbound call center environment has led us to
pushing the limits of vertical scaling. In order to treat each caller
fairly and to utilize our agents as efficiently as possible, it is
desirable to configure each client as a single queue. As far as I know,
Ast
22 matches
Mail list logo