[Asterisk-Dev] IBM/SGI implementations

[Steve Kann]

Steven Critchfield wrote:

>On Sat, 2004-11-20 at 16:28 -0500, John Todd wrote:
>  
>
>>I hadn't thought about SGI.  Do they have any special hardware tricks 
>>up their sleeves for perhaps doing codec transcoding in a more 
>>efficient manner than in the "generic" main CPU?
>>    
>>
>
>I don't know about special tricks other than the ability to add 4 way
>Itanium bricks to the "cluster" and have it just work. They have a
>special interconnect to have all the CPUs communicate via NUMA and
>therefore to the OS it is as if they all are in the same motherboard. So
>the benefit I see is in that you could get your DS3 and a couple of C
>bricks(cpu components) and start off with a nice frac DS3 setup. As you
>grow and need more channels and CPUs, you add another C brick and up
>your capacity. Unfortunately I don't have any experience with it so I'll
>leave it at that.
>  
>

I think a great "trick" to do DSP operations like codecs on cheap 
hardware is to use the power of the GPU.  This is something that Mark's 
been talking about in the past.

Much of the work of audio DSP stuff seem to be similar to the work that 
your off-the-shelf GPU can do much faster than GP CPUs can, and the 
price/performance is great.  You'd need to rewrite the codecs, and other 
DSP routines for this, but programming to a meta-library like Sh 
(http://libsh.sourceforge.net/) can allow your code to be portable 
amongst several GPU backends.

"The new GPUs are very fast. Stanford's Ian Buck calculates that the 
current GeForce FX 5900's performance peaks at 20 Gigaflops, the 
equivalent of a 10-GHz Pentium?with, according to Nvidia, even more 
speed on the horizon. Performance growth has multiplied at a rate of 2.8 
times per year since 1993, a pace analysts expect the industry to 
maintain for another five years. At this rate, GPU performance will move 
inexorably into the teraflop range by 2005. "


While moving to bigger, more flexible iron is always a strategy that can 
be made to work, it's usually not the most cost-effective.

If instead, we designed * such that you could build a cluster of cheaper 
boxes, and have them operate as a cohesive unit such that if one box 
fails, others could seamlessly take over, you'd still get much better 
price/performance than if you used scalable/fault-tolerant (read: 
expensive and complicated) hardware like this thread has been discussing.

The first step towards a true clustered solution might be designed such 
that if a box fails, you lose the calls that were presently on the box, 
but otherwise the system can keep running.   As long as you can have a 
cluster working together, and scaling to tens or hundreds of machines 
operating as a seamless unit, that might be an acceptable solution, and 
able to give you a decent number of 9's.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20041122/aeea6824/attachment.htm