Also I have seen some people reporting that the new tickless timers in newer kernels work better. You may want to try those.
Mike On Dec 7, 2009, at 11:00 AM, Anthony Minessale wrote: > 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 <[email protected]> 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?
_______________________________________________ FreeSWITCH-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
