<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
Patrick,<br>
<br>
Thank you for your suggestions.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
<br>
Matthew Roth<br>
InterMedia Marketing Solutions<br>
Software Engineer and Systems Developer<br>
<br>
Patrick wrote:<br>
<blockquote cite="mid1127261371.4118.51.camel@guru.puzzled.xs4all.nl"
type="cite">
<pre wrap="">On Tue, 2005-09-20 at 18:37 -0400, Matt Roth wrote:
</pre>
<blockquote type="cite">
<pre wrap="">List users,
Over the last few days we have been working with MCI's development lab
to test our Asterisk setup. We were using a piece of hardware called an
Abacus 5000 that is capable of creating and terminating thousands of SIP
calls. Initially, we could not get past 64 simultaneous digitally
recorded calls without having call quality issues including dropped
calls. We identified an I/O bottleneck and rectified it by digitally
recording to a RAM disk. Using this method, we were able to digitally
record 512 simultaneous SIP-to-SIP calls with 100% call completion.
Our plan is to use the MONITOR_EXEC hook to call a custom program that
will copy files to the hard disk at call completion.
</pre>
</blockquote>
<pre wrap=""><!---->
Matt,
Interesting stuff. Did you test copying of the recordings on the ramdisk
to a local harddisk also during that 512 call load? Just wondering if
that copy action wouldn't also create an I/O bottleneck and cause call
quality issues under load. Did you consider using remote storage e.g.
via nfs, a fibre channel or iSCSI link to a SAN?
Regards,
Patrick
_______________________________________________
--Bandwidth and Colocation sponsored by Easynews.com --
Asterisk-Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Asterisk-Users@lists.digium.com">Asterisk-Users@lists.digium.com</a>
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a>
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a>
</pre>
</blockquote>
</body>
</html>