Daniel,

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

Thanks again,
Steve

----- Original Message ----- From: "Daniel Salama" <[EMAIL PROTECTED]>
To: "Asterisk Users Mailing List - Non-Commercial Discussion" <asterisk-users@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:[EMAIL PROTECTED] 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@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@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@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@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@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@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

Reply via email to