[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