[Asterisk-Users] Digium Quad Span Cards

[Adam Goryachev]

On Tue, 2005-04-26 at 12:58 -0400, Matt Roth wrote:
> So it looks like processor interrupts are the culprit.
> 
> Possible solutions to this problem include (please feel free to add to 
> this list):
> - An Asterisk slave server pool ( 
> http://home.comcast.net/~mroth01/LargeAsteriskSetup.gif )
> - A TDM-VoIP gateway (Cisco, Quintum, AudioCodes, Lucent)
> - Using Sangoma cards (As per David Mandelstam, Sangoma cards use 
> proprietary drivers and there are operational setups using 4 quads per 
> machine)

Just wondering, but does the AMD multi CPU architecture improve the
interrupt handling? My understanding of that architecture is that each
CPU can deal with "it's own" PCI bus/interrupts/etc independently of
each other, and also with their own memory/etc? Would this improve the
scalability? In fact, would a multi-PCI bus system by itself 'solve' the
problem?

> I'm not confident that the Asterisk software scales well under certain 
> conditions, such as using Monitor to digitally record 16 spans of voice 
> channels, so solving the card issue may not be the last step in a large 
> installation.  If anyone has any insight on this, please post it to the 
> list.

Well, what are the overheads of monitoring a call as opposed to simply
bridging it from a digium channel to a IP channel (ie, the voice is
still passing through asterisk)?

As I see it, you have:
* Conversion from ulaw/alaw -> slinear
* Conversion from slinear -> file format (what if you record in
alaw/ulaw?)
* Disk subsystem (writing to the disk)

On a suitable system, I think the CPU involved in the transcoding from
ulaw/alaw to slinear would be minimal. Converting from slinear to gsm
for example, might be quite high, but if you record in ulaw/alaw, then
this might work.

Also, CPU overhead on disk performance should be minimal if using a
reasonable SCSI controller.

Lets see, 64000 /    8           *   30     *  8   = 1920000 bytes/sec
            bps   bits per byte    channels  spans

So, we are only writing 2 Mega Bytes / sec to the disk. That isn't
exactly a lot of load for a disk to handle.... Sure, sustained transfer
rates, interrupts, etc.... but really, 2MB/sec seems so.... slow :)

So, is it really an issue? Dunno, someone want to run a couple of spans
through monitor and try it out? We won't really know until we try it...

Just my 2c worth...

-- 
 -- 
Adam Goryachev
Website Managers
Ph:  +61 2 8304 0000                        adam at websitemanagers.com.au
Fax: +61 2 9345 4396                        www.websitemanagers.com.au