Hey ho,
I suppose you are the person from the digium forum :) The reason i recommended you to use a ramdisk is because i think the problem with recording to disk is saving 20ms of stream 1, then 20 ms of stream 2, then 20ms of stream 3 etc etc.... meaning you write everytime very small things. (with a lot of seeking). Our best test results were with: - buffering the recordings to a ramdisk, then - on low load (at night) copy the files over the network (easy to shape the pipe, so that you dont overload anything), This way, the memory buffer will take care of the 'fragmentation' and not your harddisk. - on the remove server, do all the mixing / indexing etc. (i really don't mixing or converting between audio formats on the same server as asterisk). If you want to go even freakier, run asterisk (or you complete distro) from a ramdisk. Oh, another thing, for the people trying this the performance of hdparm is not linear with the quality of your calls, tweaking your disks to be faster will not help for asterisk when you do a copy. (in general). I thought over your suggestion to use a sniffer to do the recordings, you might pull it off, but will have to write your own to do so. (or go to the expensive version of commercial sniffer applications). Zoa. --------------------- www.asteriskguru.com Matt Florell wrote:
On 9/20/05, *Matt Roth* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: Patrick, Thank you for your suggestions. Our initial runs were recording directly to an NFS mount and they experienced the same problems as recording to the local disk. In our final setup, the copy will be done to an NFS mount as long as it exists, falling back to local disk only when the NFS server is down. The theory that we're running on is that any I/O bottlenecks (or network latencies in the case of NFS) only matter when they are bound to a call in progress. In that scenario, the bottleneck would introduce a latency in Asterisk's handling of the RTP packets causing call degradation and drops. By decoupling I/O from live calls and performing the copies (a very lightweight operation) in a separate process, we hope to not affect Asterisk's real-time handling of the RTP packets. Because of limited access to the test equipment, we were only able to test up to storing the digital recordings on a RAM disk. Please shoot holes in this setup if you see any weaknesses. Better today than on our go-live date. Thanks, Matthew Roth InterMedia Marketing Solutions Software Engineer and Systems Developer Hello, I'm very interested in the specifics of your setup. How much space is on the RAM disk? What kind of RAM drive is it? What format are you recording to? What codec are the SIP calls being placed over? We've run into the "Avoided deadlock" recording issues several times when trying to do more than 50 concurrent recordings. Changing the ast_channel_lock loop from 10 to 20 has helped somewhat reduce the warnings and reduce audio gaps on the recordings, but what is really needed for more robust recording is a configurable recording buffer that wouldn't freak out if a 10ms delay occurs. Good luck and please keep us updated on your progress, MATT--- ------------------------------------------------------------------------ _______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- 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
