[Asterisk-Dev] res_monitor improvement

Matt Florell astmattf at gmail.com
Sun Aug 14 18:06:39 MST 2005


I my experience on several test systems using SCSI RAIDs, SATA or IDE
drives you cannot reliably handle over 100 recordings at once without
loosing audio data even if for a split second. Those audio drops
usually show up as a channel_walk_locked warnings in asterisk and you
can hear them in the audio file as a noticable missing section of
audio. Our systems always use a separate physical drive(s) for
/var/spool/asterisk/monitor so other apps IO shouldn't affect the disk
response.

Different systems have different failing points as far as the number
of skips per day, but I have never been able to do 100 concurrent
recordings without some loss of audio. Now keep in mind I'm talking
about only loosing 0.001% or less of the audio attempted to be
recorded for a day, but when you do things like 3rd party long
distance switching verification and other types of audio recording
where you need 100% of the audio to be there, it become a problem. In
these types of application if you lose a half second of audio in the
wrong place on a single recording you could potentially loose a lot of
business.

We have found changing the channel_walk loop from 10 to 20 or 30 can
greatly reduce the number of skips, But it would be good to test a
system that allowed for a larger recording write buffer to be
accumulated if the disk is unable to accept the data at that
millisecond for a specific recording..

MATT---

On 8/14/05, Brian West <brian.west at mac.com> wrote:
> You're over thinking this.  Even on a busy system it won't matter.  You're
> only going to get 600 calls on a box before it starts to break (If that
> many)... disk I/O should be more than enough to take that many calls.
> 
> /b
> 
> 
> On Aug 14, 2005, at 7:24 PM, Boris Bakchiev wrote:
> 
> 
> It is when it comes to writing. 
> 
> No buffering at all as far as I can see. 
> 
> All data gets dumped to hdd right away. 
> 
> I guess linux caching should take care of it, but on a busy system I can 
> 
> afford to dedicate 1GB ramdisk (or 1GB tmfs) for temporary storage of 
> 
> files. 
> 
>  
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
>



More information about the asterisk-dev mailing list