[Asterisk-Users] SUCCESS - 512 Simultaneous Calls with Digital Recording

[Zoa]

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* <mroth at imminc.com <mailto:mroth at imminc.com>>
> 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 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
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20050921/f3fd593a/signature.pgp