[asterisk-users] asterisk 1.8 on Solaris/sparc
I've got the latest asterisk 1.8 running on a Netra X1 with Solaris 10 u10. The system itself is happy and phone calls (between two parties) seem fine. Unfortunately, when a caller listens to a Playback recording, there seems to be moments of stutter - perhaps 1 second of stutter for every 10 seconds of Playback. The stutter is not consistent at the same point of the playback file. To eliminate encoding as an issue, I have only codec_ulaw/format_pcm loaded and the recording is ulaw. I've niced down the asterisk process to -19 even though I don't see asterisk taking more than 3% cpu. Is this behavior indicative of a timing problem? loading res_timing_pthread.so makes things horribly worse. i don't believe any other software timer is available for Solaris/sparc, right ? other thoughts ? Thanks, -- Jeremy Kister http://jeremy.kister.net./ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 1.8 on Solaris/sparc
On 7/18/2012 2:27 AM, Jeremy Kister wrote: I've got the latest asterisk 1.8 running on a Netra X1 with Solaris 10 u10. .. ok, if the system weren't Solaris - let's say it was Debian Linux, what would be on the list of things to check for ? -- Jeremy Kister http://jeremy.kister.net./ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 1.8 on Solaris/sparc
On Wed, 2012-07-18 at 02:27 -0400, Jeremy Kister wrote: > I've got the latest asterisk 1.8 running on a Netra X1 with Solaris 10 u10. > > The system itself is happy and phone calls (between two parties) seem fine. > > Unfortunately, when a caller listens to a Playback recording, there > seems to be moments of stutter - perhaps 1 second of stutter for every > 10 seconds of Playback. The stutter is not consistent at the same point > of the playback file. > > To eliminate encoding as an issue, I have only codec_ulaw/format_pcm > loaded and the recording is ulaw. I've niced down the asterisk process > to -19 even though I don't see asterisk taking more than 3% cpu. > > > Is this behavior indicative of a timing problem? loading > res_timing_pthread.so makes things horribly worse. i don't believe any > other software timer is available for Solaris/sparc, right ? > > other thoughts ? Perhaps system too busy, disk not fast enough? before doing a play-back, run "iostat 1" in another window Incase iowait is too high, try moving the files with the playback sound/speech upon tmpfs (thus eliminating the hard disk) hw -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 1.8 on Solaris/sparc
On 7/19/2012 3:50 AM, Hans Witvliet wrote: Perhaps system too busy, disk not fast enough? before doing a play-back, run "iostat 1" in another window interesting. the stutter certainly correlates to minor amounts of disk i/o. when there is no stutter, there is nothing to report. but a minor amount of wait/busy lines up with the stutter. # iostat -znx 1 extended device statistics r/sw/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 72.00.0 456.0 0.1 0.11.00.9 2 4 c0t0d0 0.0 72.00.0 456.0 0.1 0.11.20.9 2 4 c0t2d0 extended device statistics r/sw/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device extended device statistics r/sw/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device Incase iowait is too high, try moving the files with the playback sound/speech upon tmpfs (thus eliminating the hard disk) That's worth a shot. I dont have big enough tmpfs to copy the whole sounds spool, so i: # cd /var/lib/asterisk/sounds/en/ # mkdir /tmp/sounds # ln -s /tmp/sounds tmpfs # cp mysound.ulaw tmpfs Playback(tmpfs/mysound) But it didnt help, still randomish stutter lining up with the disk. this is a great help, at least i can start hacking at things now. Thanks, -- Jeremy Kister http://jeremy.kister.net./ -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 1.8 on Solaris/sparc
On Wednesday 18 July 2012, Jeremy Kister wrote: > I've got the latest asterisk 1.8 running on a Netra X1 with Solaris 10 u10. > > The system itself is happy and phone calls (between two parties) seem fine. > > Unfortunately, when a caller listens to a Playback recording, there > seems to be moments of stutter - perhaps 1 second of stutter for every > 10 seconds of Playback. The stutter is not consistent at the same point > of the playback file. It sounds as though you may have run into an obscure issue with the default filesystems of Solaris and Linux having diametrically-opposed design philosophies with regard to caching policy. The following is a bit of an over-simplification, but here goes anyway. Solaris is built for robustness: it doesn't even return from a write to disk until it has verified that the data was written successfully. Linux is built for speed: it caches everything it possibly can, serves reads straight from cache and never commits anything to disk unless it's about to run out of RAM or a shutdown is requested. If you write a program that uses temporary files a lot, you can test on Linux on a scrapper and find it blisteringly fast -- only for it to slow to a crawl when you deploy on Solaris. This is because under Linux, short-term temporary files can be written to cache, read from cache and deleted from cache, all without ever seeing oxide -- but Solaris, unless instructed otherwise, will insist to write the whole lot to disk anyway. If this is what's causing your problems, you will have to do some low-level tweaking. But it *is* fixable. -- AJS Price Engines Ltd. DDI: 01283 707058. -- AJS Answers come *after* questions. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] asterisk 1.8 on Solaris/sparc
On Wednesday 18 July 2012, Jeremy Kister wrote: > I've got the latest asterisk 1.8 running on a Netra X1 with Solaris 10 u10. > > The system itself is happy and phone calls (between two parties) seem fine. > > Unfortunately, when a caller listens to a Playback recording, there > seems to be moments of stutter - perhaps 1 second of stutter for every > 10 seconds of Playback. The stutter is not consistent at the same point > of the playback file. It sounds as though you may have run into an obscure issue with the default filesystems of Solaris and Linux having diametrically-opposed design philosophies with regard to caching policy. The following is a bit of an over-simplification, but here goes anyway. Solaris is built for robustness: it doesn't even return from a write to disk until it has verified that the data was written successfully. Linux is built for speed: it caches everything it possibly can, serves reads straight from cache and never commits anything to disk unless it's about to run out of RAM or a shutdown is requested. If you write a program that uses temporary files a lot, you can test on Linux on a scrapper and find it blisteringly fast -- only for it to slow to a crawl when you deploy on Solaris. This is because under Linux, short-term temporary files can be written to cache, read from cache and deleted from cache, all without ever seeing oxide -- but Solaris, unless instructed otherwise, will insist to write the whole lot to disk anyway. If this is what's causing your problems, you will have to do some low-level tweaking. But it *is* fixable. -- AJS Price Engines Ltd. DDI: 01283 707058. -- AJS Answers come *after* questions. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
