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.
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)
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?
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)?
Also, any experience with Asterisk on an Opteron out there? Any
unexpected issues? How about card drivers?
Thanks! I hope this spurs an interesting exchange of ideas that is of
value to many.
I have Dual Opteron 2 GHz with 4 Gb memory. I don't have huge load right now, and system load is almost 0.00 even if it uses slinear to G.729 transcoding. I have Wildcard 410P installed. Works good for me. 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. > > 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) > > 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? > > 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)? > > Also, any experience with Asterisk on an Opteron out there? Any > unexpected issues? How about card drivers? > > Thanks! I hope this spurs an interesting exchange of ideas that is of > value to many. > > _______________________________________________ > Asterisk-Users mailing list > Asterisk-Users@lists.digium.com > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users-- All the Best! Sergey. ========================Sergey Kuznetsov President/CEO High Intellectual Technologies, Inc. Web: http://www.hitcalls.com E-mail: sergey.kuznetsov@highintellect.com Business phone: (416) 548-9700 Mobile phone: (647) 287-8448
On Fri, 2005-02-04 at 11:21 -0800, 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.This I guess depends mostly on what channels you are using. Since a fully loaded E1 is only 2mbps and you are unlikely to want to place more than a few per machine before you start building redundancy into your systems, You will be moving less data than a 100mb ethernet card, but on a realtime basis instead of being able to delay service. On the other hand, if you are talking all VoIP, it might help to service that NIC a little faster to keep all your callers happy with latency.> 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)Other than a few structures relating to each call and it's state, you only pass about 160 samples around to be worked on at a time and in signed linear thats only 320 bytes. So per call incremental memory shouldn't be very much, probably on the order of a few K at best. We run our main systems right now with only 256m and they handle T1 capacity.> 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?Disk IO isn't a killer. You just have to be careful about not pounding the drives. Many of us record calls directly to the main drives of the asterisk machine. Voice mail goes straight to main drives. Just don't put a database that is going to see much more than extremely sparse access on the same machine.> 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)?Is the floating point unit that much faster than an equivalent clocked non 64 bit system? You will probably see similarly improved performance on the same clock speed rises. Otherwise, I don't know much about the math being used internally to help on that question. Hope that sharpens some of your questions to get the data you are looking for. -- Steven Critchfield <critch@basesys.com>
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