On Feb 4, 2005, at 11:21 AM, Spencer Nassar wrote:
I've been doing a lot of background reading/searching of this list, voip-info.org, and Google, looking to define a good candidate for a server platform. I'm very interested in thoughts from others! So here goes...
Axiom 1: if you are not doing doing much transcoding (converting between codecs), the bottleneck for supporting high volumes of simultaneous calls is system bus speed, not CPU power
---> points to a 64 bit AMD Opteron system, and maybe just one of the two processor slots populated. Bus is twice as wide as a 32 bit system, and operates at 1.8GHz (a lot faster than a 64 bit Zeon system). Then add the second processor to the board if you see you need it.
Er, not really. First, the closest thing to a "system bus" in the Opteron system is really only 16 bits wide at its widest, and it probably only 8 bits wide by the point that it talks to your PCI bridge. But, measuring the system's throughput on the basis of how many wires its internal plumbing uses is kind of nutty--the Opteron can move more data over an 8-bit Hypertransport link then a Pentium III could over its 64-bit bus. And, in *either* case, the system bus isn't going to be a problem for any sort of telephony application. I mean, even an 8-bit 800 MHz HT link is good for 12.8 Gbps each direction. That's a lot of T1s.
The real problem seems to be either CPU performance for transcoding or (more frequently) PCI bus bandwidth and latency. Low-end systems with a single 32-bit PCI bus are going to have problems with more then one Digium card. Systems with multiple busses *should* be able to scale further, but I haven't seen any sort of testing to back this up.
Axiom 2: Get lots of memory
---> I haven't seen this quantified, and plan to do some testing. I'll post results here, but can anyone share any insights? I'm planning to start at 2GB, and go up from there if I see swap getting used.
- what would an alaw to alaw connection consume (if it didn't hand off)?
- what about a 5 call alaw meetme bridge (and how much memory per incremental caller)
Again, not really. Asterisk doesn't use a whole lot of RAM. Make sure that it's not swapping, but even 256 MB is probably enough most of the time.
Axiom 3: Don't allow any disk IO
---> I'm assuming this is related to #2 - get lots of memory to avoid swap to disk. Other issues or thoughts?
Well, if you have a really nasty IDE bus with DMA and interrupts disabled, then disk I/O could probably be a problem. Other then that, it shouldn't matter. As others have said, don't run a big DB server on the same box, but a bit of disk I/O isn't a problem.
Axoim 4: Come codecs will take advantage of the faster floating point of a 64 bit system
---> unknown... has anyone seen this? Will Asterisk, compiled in a 64 bit Linux environment, reap these or other benefits from being on a 64 bit system (other than the system bus speed)?
Dunno. I suspect that some codecs *could* benefit from 64-bit math, but I doubt that any of the current codecs are tuned for 64-bit CPUs.
Scott
_______________________________________________ Asterisk-Users mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
