What codec are the calls? What codec are you recording in? I would try some non-Dell hardware, I would also try a less bloated Linux Distro, something like Slackware, just to see if that had any effect. And make sure you use the megaraid2 linux drivers.
MATT--- On 12/13/05, Matt Roth <[EMAIL PROTECTED]> wrote: > Matt Florell wrote: > > >Hello, > > > >Need some more information here: > >- hardware specs (including what kind of hard drives?) > The Asterisk server is a Dell PowerEdge 6850 with the following specs. > Please note that we are NOT recording to the hard drive. We are > recording to a RAM disk as detailed here > (http://voip-info.org/wiki/view/Asterisk+Dimensioning) under the heading > "512 simultaneous SIP-to-SIP calls with Digital Recording". > Unfortunately, the scalability tests we did at that time assumed that if > call quality was good, so was the quality of the recording. > > Processor: Quad Intel Xeon 3.16GHz/1MB Cache > Memory: 20 GB DDR2 400MHZ Single Ranked DIMMs (4 GB System / 16 GB RAM Disk) > Hard Drive: Two 73GB, U320, SCSI, 1IN 15K Configured in a RAID 1 (Mirrored) > Hard Drive Controller: Embedded RAID - PERC4 Integrated (Driver: > megaraid_mm, megaraid_mbox) > Everything else: > http://www.dell.com/downloads/global/products/pedge/en/PE6850_specs.pdf > > >- Linux kernel version > 2.6.12-1.1376_FC3smp (Fedora Core 3). > > >- running Xwindows? > No. > > >- Asterisk version > ABE-A.2-beta (Asterisk Business Edition A.2 beta). > > >- kind of calls you are recording (Zap, SIP, IAX, Meetme, ...) > Calls originate on the PSTN and are handled by a Cisco AS5400 Universal > Gateway that is a SIP peer of Asterisk. The AS5400 converts the calls > from TDM channels to VoIP (SIP) channels before sending them to > Asterisk. The Asterisk dialplan then routes them to one of our agents, > who are using SNOM 320 VoIP (SIP) phones. Essentially all of our calls > are SIP-to-SIP, with absolutely no protocol bridging or transcoding > occurring on the Asterisk server. > > The Asterisk server handles the following major tasks: > > - Routing calls through the dialplan to (dynamic) agents in the > appropriate queues. > - Adding/removing agents to/from queues via AddQueueMember and > RemoveQueueMember (NO static agents!). > - Recording calls via the Monitor application directly to RAM disk. > Calls are moved to a remote machine for mixing. > - ChanSpy-based quality assurance of calls. Neither ChanSpy nor the > quality of the calls themselves is affected by the problem. > > >- how many recordings at once > Anywhere from 5 to 30 concurrent recordings. This is not our planned > peak, but it's where we've experienced the problem so far. We have not > yet determined if the number of concurrent recordings is an issue, but > we are considering it. We also haven't determined if the problem gets > worse as the number of recordings increases, but it definitely exists > throughout that entire range. > > >In my experience, HyperThreading does not cause recording problems, > >it's usually a disk issue. When we had issues, switching to fast SCSI > >drives on a MegaRAID 320-1 with the megaraid2 linux driver solved all > >of our problems(skips and clicks/pops) > > The disk issues also directly interfere with call quality, as our > previous scalability tests showed. Digium seems to think that the issue > is scaling (some resource contention that causes a bit of audio to be > unavailable when the write occurs). I see their point, but given our > hardware and the current call volume I'm not completely sold on it. > Could it be a configuration issue (file handles, interrupts, etc...)? > > >MATT--- > > Colin Anderson wrote: > > >Matt Roth: FWIW, I am recording 1000-1500 calls a day (as of 8:52PM today, > >1482 calls!) of various length on my Netfinity with the onboard IBM RAID > >controller in RAID 5 Ultra 320 SCSI with suprisingly good quality. As the > >other Matt indicated, maybe what is needed here is an intelligent > controller > >to offload some of the chore. > > > >No definite solution here, but at least it's another data point to > compare. > > I appreciate any information contributed by list users. It's by far the > most valuable resource available to me. > > >On 12/12/05, Matt Roth <[EMAIL PROTECTED]> wrote: > > > >>List users, > >> > >>I'm using the Monitor application to record calls. Most of the > >>recordings are audible, but contain skips accompanied by a popping > >>sound. Sometimes they are isolated, sometimes they appear in groups. > >>Call quality is excellent and seems unaffected by whatever is causing > >>this problem. > >> > >>If anyone has experienced this problem before, I'd appreciate if you'd > >>share what the source was and any tips on eliminating it. I contacted > >>Digium tech support and they suggested turning off hyperthreading. I > >>have done that, but I won't know if it improved things until tomorrow. > >> > >>The machine is running at a moderate call volume and is always at least > >>90% idle. I'm not seeing any "Avoided deadlock" messages in the logs. > >>If you need any more information, I'd be happy to provide it. > > Thank you, > > Matthew Roth > InterMedia Marketing Solutions > Software Engineer and Systems Developer > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users