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?
> MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com>
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@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@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
> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com>
> sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org>
> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org>
> pstn:213-799-1400
>
> _______________________________________________View this message in context: http://old.nabble.com/Choppy-sound-with-PCMU-tp26594250p26678873.html
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
--
Sent from the Freeswitch-users mailing list archive at Nabble.com.
_______________________________________________