[Freeswitch-users] Choppy sound with PCMU

Mon Dec 7 08:00:17 PST 2009

Did you do each thing alone too to tell the difference?
-hp alone, disable monotonic alone (i did not see you mention the disable
monotonic)

as for your 4ms thing, yes we require high resolution timing, if we ask to
sleep 1000 microseconds that is what we need it to sleep for or at least as
close as possible, and the main reason that thread is never sleeping is
because you can't actually count on it to run every 1ms but you mostly can.
Hence the whole philosophy on only making 1 thread run hot all the time to
ensure that the rest don't have to repeat the same algorithm.  We focus on
high end performance this was the point of your experimentation because we
will need to use a compile time defines and other logic to make it more
efficient on your platform, a platform which we are not using.  I am curious
what would happen if you install Kristian's astlinux on one of your devices,
i think you should also compare the kernel versions.

What OS are you running anyway?

Here are some more things to try (running plain trunk with no mods) do these
systematically each alone and all together with/without -hp or disable
monotonic etc to see what different combos create

comment out this line (line 10)
#define DISABLE_1MS_COND

rebuild, this tells it to run a conditional at 1ms in the same timer thread
which will make all the switch_cond_next share a 1ms conditional instead of
doing microsleeps

next

some kernels/devices work better using select(0) for sleep where others work
better using usleep.
comment out line 109
apr_sleep(t);

and try
usleep(t)

also mac works better using nanosleep so you could try changing it so it
uses the code starting at 101 instead.

also your claim about JS should be investigated because I do not think it
should be the case.
but you may want to move this to a jira http://jira.freeswitch.org

As for the asterisk comparison,
not sure how to answer you, that's your decision.

On Mon, Dec 7, 2009 at 9:28 AM, eaf <erandr-junk at usa.net> wrote:

>
> Here is what I found...
>
> I tried high-priority scheduling as per your suggestion, reniced the
> program
> explicitly, rewrote timer thread to sleep on cond. variable and activate
> only when there are timers and only when the timer actually had to be
> clicked, turned off SQL thread and removed polling from sofia profile
> thread.
>
> That pretty much eliminated all idle 1ms sleepers that were there except
> for
> three in sofia itself (su_epoll_port). And when I was about to be happy, I
> found that two outgoing calls through my VOIP providers when bridged
> together showed terrible distortions. I undid all my changes, tried 1.0.4,
> trunk (noticed btw that when I bridge two calls via loopback in JS in the
> trunk I must keep JS running, or the calls get terminated - NOT the same as
> in 1.0.4 where exitting JS left calls running), got pretty much the same
> sad
> results. At the same time calls bridged by freeswitch between LAN and any
> of
> the VOIP providers behaved just fine. And calls bridged by Asterisk any way
> were fine too. So that pretty much looked like the end of the freeswitch
> trials for me.
>
> But then I timed your code, mine and found that all those 1ms sleeps that
> your timer thread was doing (and all those pollers were doing as well) were
> actually 4ms sleeps because you know what unless kernel is configured with
> HZ=1000, you can't sleep for less than 4ms (HZ=250) or perhaps even 10ms
> (HZ=100). Mine was 250.
>
> This actually meant that the original timer thread was firing once,
> sleeping
> for 4ms, firing 3 more times back-to-back, sleeping for 4ms more, firing 4
> times back-to-back, etc. It was still firing 20ms timers on time, but 30ms
> ones of course were not, since 30ms doesn't divide by 4 evenly. Plus
> whoever
> relied on runtime.reference or switch_micro_time_now() were kind of screwed
> because both were running jumpy. Plus whoever assumed that apr_sleep(1000)
> or cond_yield() was sleeping for 1ms were also in for a surprise. It felt
> satisfying to find that, however it didn't explain why the same distortions
> were observed with rewritten timer thread and disabled RTP timers.
>
> Anyway, I sighed (pretty much like you) and recompiled the kernel with
> HZ=1000. Recompiling kernel on these ALIX boards is fun. If smth goes
> south,
> you need to hook up serial console and see what the heck went wrong.
>
> That eliminated distortions, ha! But made freeswitch more CPU hungry. Now
> the remaining 1ms threads sitting in sofia epoll were really polling for
> 1ms, not 4, and freeswitch was consistently sitting in the first line of
> the
> top chart showing 3% CPU utilization when idle.
>
> Don't know whether it's because of the remaining epolls in sofia or whether
> it's because there are still some threads left in freeswitch that I
> neglected to change because they were sleeping with 100ms interval, so I
> figured, who cares. Maybe when all things come together (sofia, 100ms*N)
> freeswitch ends up spending 3% of CPU while doing pretty much nothing.
>
> Btw, compared with Asterisk, the latter is not even visible on the first
> top's screen and spends 1% CPU when bridging two G711 calls and recording
> them to disk.
>
> So, at this time I have both original Asterisk and FS setups running. One
> is
> seemless but clumsy in configuration, the other one is neat and stylish but
> too preoccupied with smth... Should I look into sofia epollers? That's kind
> of deep in the code. Or should I just stick with Asterisk?
>
>
>
>
>
> Anthony Minessale-2 wrote:
> >
> > There is another user here with a 300mhz box.  I am willing to
> investigate
> > this improved performance for weak devices but I need to do it in a sane
> > cross-platform way.
> >
> >
> > On Fri, Dec 4, 2009 at 1:32 PM, Yossi Neiman
> > <freeswitch at cartissolutions.com
> >> wrote:
> >
> >> A word to the wise to the general FreeSWITCH community:  If Anthony
> >> Minessale suggests that you try to do any number of things, it's a very
> >> good idea to try all those ideas before continuing on.  I've known him,
> >> MikeJ, and bkw for several years, and they almost always have very good
> >> ideas as to troubleshoot a problem in FreeSWITCH.  It's extremely
> >> frustrating to try to help people out who won't try the provided
> >> suggestions first.
> >>
> >> And note directly to "eaf" - bogomips is quite possibly the least
> >> significant bit of data about a cpu that you will get out of
> >> /proc/cpuinfo...  The name itself - bogo, means bogus.
> >> http://en.wikipedia.org/wiki/Bogomips
> >>
> >> -Yossi
> >>
> >> _______________________________________________
> >> FreeSWITCH-users mailing list
> >> FreeSWITCH-users at lists.freeswitch.org
> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> >> UNSUBSCRIBE:
> http://lists.freeswitch.org/mailman/options/freeswitch-users
> >> http://www.freeswitch.org
> >>
> >
> >
> >
> > --
> > Anthony Minessale II
> >
> > FreeSWITCH http://www.freeswitch.org/
> > ClueCon http://www.cluecon.com/
> > Twitter: http://twitter.com/FreeSWITCH_wire
> >
> > AIM: anthm
> > MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com><
> MSN%3Aanthony_minessale at hotmail.com<MSN%253Aanthony_minessale at hotmail.com>
> >
> > GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
> <PAYPAL%3Aanthony.minessale at gmail.com<PAYPAL%253Aanthony.minessale at gmail.com>
> >
> > IRC: irc.freenode.net #freeswitch
> >
> > FreeSWITCH Developer Conference
> > sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org><
> sip%3A888 at conference.freeswitch.org<sip%253A888 at conference.freeswitch.org>
> >
> > iax:guest at conference.freeswitch.org/888
> > googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
> <googletalk%3Aconf%2B888 at conference.freeswitch.org<googletalk%253Aconf%252B888 at conference.freeswitch.org>
> >
> > pstn:213-799-1400
> >
> > _______________________________________________
> > FreeSWITCH-users mailing list
> > FreeSWITCH-users at lists.freeswitch.org
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> > http://www.freeswitch.org
> >
> >
>
> --
> View this message in context:
> http://old.nabble.com/Choppy-sound-with-PCMU-tp26594250p26678873.html
> Sent from the Freeswitch-users mailing list archive at Nabble.com.
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>

-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
pstn:213-799-1400
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20091207/a83d6006/attachment-0002.html 