[Asterisk-Dev] res_monitor improvement

[Brian West]

If you use monmux the audio before writing it out to disk you'll cut  
your disk I/O in half.  Then you can also lower that by choosing gsm  
or something other than raw or wav.

/b

On Aug 14, 2005, at 8:06 PM, Matt Florell wrote:

> 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
>>
>>
>>
> _______________________________________________
> 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
>