[Asterisk-Users] Asterisk Hardware Recommendation

Steve Totaro asterisk at totarotechnologies.com
Fri Apr 29 10:12:22 MST 2005


Daniel,

Thanks alot for this post.  You were right on time with valuable 
information.

Thanks again,
Steve

----- Original Message ----- 
From: "Daniel Salama" <dsalama at user.net>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" 
<asterisk-users at lists.digium.com>
Sent: Friday, April 29, 2005 12:37 PM
Subject: Re: [Asterisk-Users] Asterisk Hardware Recommendation


> Sure.
>
> I setup a small lab on a machine with 4 T1s and 36 agents logged in.  The 
> system was configured to Monitor all outbound calls as well as  monitor 
> all calls distributed by Queue app (monitor-format setting in 
> queues.conf).
>
> When recording to local disk, everything was working fine. Agents were 
> busy 99.5% and there were at least 30 calls waiting in Queue to be 
> distributed. Average call conversation length was about 7.5 minutes.
>
> Then I mounted /var/spool/asterisk/monitor via NFS using 10/100 Fast-E.
>
> The moment we pushed the load on the Asterisk machine, everything  worked 
> for about 40 seconds. Then call quality started suffering  significantly. 
> Chopped audio. Bad audio. No audio. Good audio. You  could imagine. So we 
> stopped the test.
>
> Then we unmounted the NFS drive and repeated the test again. Everything 
> worked fine again.
>
> The machine we tested asterisk on is a dual Xeon 3 GHz with 2G RAM. 
> During all tests, CPU utilization was about 55% on the average (for  each 
> CPU). Memory usage was under 1G.
>
> I would say I need to try more troubleshooting. Maybe there was 
> congestion on the Fast-E, although preliminary analysis indicates there 
> were no CRC errors, collisions, or packet loss.
>
> The NFS machine was completely idle.
>
> Last, we repeated the test over a 1 hour period. This time, Monitor was 
> recording on local drives and we were copying files every 15 minutes  with 
> a background process (perl script) to NFS mount point. Everything  worked 
> fine as well.
>
> I don't know if these tests are conclusive yet. However, from the  results 
> so far, I would recommend staying away from recording to NFS  mounted 
> point. I will continue running simulations to see if anything  else can be 
> identified.
>
> Thanks,
> Daniel
>
> On Apr 28, 2005, at 7:26 PM, Matt Roth wrote:
>
>> Daniel,
>>
>> Could you expand upon your experience recording to an NFS mounted  drive.
>>
>> We are looking to use a TDM-VoIP gateway to route 16+ spans to a  single 
>> Asterisk server.  We were hoping to Monitor using the following  scheme:
>>
>> - Monitor application executed on Asterisk server (no 'm' flag)
>> - Pick a codec that the Monitor application can record in natively so 
>> that no transcoding is done on the leg files (can this be done?)
>> - Record the leg files to an NFS mounted drive on a remote machine
>> - Have soxmix take care of mixing and transcoding the leg files into  the 
>> desired format on the remote machine
>>
>> According to you this now looks like a VERY BAD IDEA.
>> Does anyone out there have any experience using monitor to digitally 
>> record large numbers of spans (16+) on a single Asterisk server using  a 
>> VoIP gateway instead of TDM cards?  Is it feasible?  We are trying  to 
>> keep the Asterisk server as slim as possible, but would like to  stick to 
>> one box so that we can have centralized queuing,  configuration, and 
>> reporting.
>>
>> Has anyone had any luck using Monitor to record to an NFS mounted  drive? 
>> Are there any other options to remove the overhead of the disk  subsystem 
>> when recording calls?
>>
>> Thanks,
>>
>> Matthew Roth
>> http://voip-info.org/tiki-index.php? 
>> page=Running%20Asterisk%20on%20Debian
>>
>> Daniel Salama wrote:
>>
>>> Thank you again. I will definitely do that. By "cheaper" asterisk 
>>> servers, do you mean single-CPU machines that can handle Quad T1s and 
>>> still do the call monitoring?
>>>
>>> BTW, I tried the monitoring without the 'm' option and mounted the 
>>> audio directory via NFS. Big NO NO for everyone. Just do what Matt 
>>> says: copy the -in and -out to archive server separately several  times 
>>> a day :) - don't record to NFS mounted drive.
>>>
>>> Thanks,
>>> Daniel
>>>
>>> On Apr 28, 2005, at 6:42 PM, mattf wrote:
>>>
>>>> I have never been able to do more than 50 concurrent recordings with 
>>>> Zap ->
>>>> SIP phone calls without the audio skipping and/or breaking up. Also, 
>>>> if you
>>>> are using Digium TE4XXP and want to do a lot of recording I would 
>>>> recommend
>>>> against a SCSI RAID card because of the interrupt conflicts that you 
>>>> will
>>>> run into over time. I would recommend a couple of cheaper Asterisk 
>>>> servers
>>>> with a dual T1 or Quad T1 board in them and SATA drives, with a nice 
>>>> big
>>>> archive server that the audio will be copied to several times a day. 
>>>> Also,
>>>> do not record(Monitor) with the 'm' flag on because this will also 
>>>> lead to
>>>> more disk read-write while you are already trying to write another  100 
>>>> or so
>>>> streams. Offload the -in and -out files to the archive server and  let 
>>>> it
>>>> soxmix them together instead. This is the method that we have  settled 
>>>> on for
>>>> our 12 Asterisk servers and it works rather well for us.
>>>>
>>>> MATT---
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Daniel Salama [mailto:dsalama at user.net]
>>>> Sent: Thursday, April 28, 2005 5:56 PM
>>>> To: Asterisk Users Mailing List - Non-Commercial Discussion
>>>> Subject: [Asterisk-Users] Asterisk Hardware Recommendation
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I've been reading on the wiki as well as on this list, different
>>>> suggestions of what to look for when designing an asterisk server  with
>>>> a lot of traffic. By "a lot" of traffic, I mean a box with a a  TE4XXP,
>>>> that will be hit to full capacity (96 simultaneous calls). This box
>>>> will also deliver these calls to SIP users and record all their
>>>> conversations via Monitor.
>>>>
>>>> I've heard that it's not necessarily a matter of memory (RAM) nor the
>>>> need to have a multi-processor machine. But what really matters is 
>>>> that
>>>> the motherboard (architecture) is designed to handle such a high 
>>>> amount
>>>> of interrupts generated by the TE4XXP, the NIC, the storage array
>>>> (whether it's SCSI or IDE or SATA).
>>>>
>>>> Does anyone have experience with particular brands of either
>>>> motherboards they recommend are capable to handle this or complete
>>>> systems (e.g. Dell xxxx or whichever brands), that are ready for  this?
>>>>
>>>> Thanks,
>>>> Daniel
>>>>
>>>> _______________________________________________
>>>> Asterisk-Users mailing list
>>>> Asterisk-Users at 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
>>>> _______________________________________________
>>>> Asterisk-Users mailing list
>>>> Asterisk-Users at 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
>>>
>>>
>>> _______________________________________________
>>> Asterisk-Users mailing list
>>> Asterisk-Users at 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
>>>
>> _______________________________________________
>> Asterisk-Users mailing list
>> Asterisk-Users at 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
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at 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
> 




More information about the asterisk-users mailing list