On May 14, 2010, at 4:46 PM, Matt White wrote: >> >> Have you tried a recent git build of FreeSWITCH? > > I'm using a build from early-mid April, I will grab the latest and re-test, > but it did seem like the higher I set the HZ the more CPU it consumed at idle. > However, if its an issue with freeswitch cycling through hurrying up to wake > and then idle, its probably not hurting performance. > > Contrary to popular >> belief, tick-less is not so accurate as you might think, and can be more >> expensive cpu wise. >> >>> Its also not an issue I can replicate with older builds of freeswitch. >>> >>> And considering most if not all the major distros are shipping or will ship >> with tickless kernels enabled, its not fair to simply call this an issue >> with >> "badly configured" kernels. Currently the latest suse, debian and ubuntu >> ship with this by default as do the current RHEL6 betas. Even if the >> general >> advise will be to disable tickless, that means we have to know whats best to >> set the timer to once you disable tickless. >> >> Again, your expectations and reality may be at odds here. Just because >> major distros defaults are moving in a bad direction for accurate and >> efficient timing doesn't mean that its something that can be fixed from user >> space, regardless of your preference that it would be. There are a lot of >> tradeoffs in doing soft timing between accuracy and performance, and it is a >> moving target. Code from the latest release has a startup analysis for the >> soft timer to try to get the best balance, but this can only get us so far. >> > > Agreed, I simply stated a preference for a freeswitch fix only because I can > guess > that as more and more distros move to this method the number of times it will > appear in the mailing list will increase ;-) > Honestly, I am quite fine with changing the kernel parameters. It was only > the investigation into the issue that made me > question what the best timer would be as we will now have to instruct users > exactly what to set.
I am going to take a look at this and make sure we don't have a trip up here, but I have seen things in the kernel going in entirely the wrong direction for this stuff to work well, so I am not that hopeful. >>> >>> So my real question is do we know how different timers affect things like >> sipxbridge and relay for remote workers. If 250 is too low and 1000 is >> consider the max for freeswitch do we know of a good balance? >>> >> >> Bridging calls should not have this same issue, you simply shuffle audio in >> each direction as it arrives, no timing required. The issue comes when you >> are actually generating a stream such as in sound file playback and >> conferencing. >> >> 1000 is what it should be set to. >> > > What are your thoughts on the high-resolution timer parameter? Set or no > set? I see its enabled in SLES 11 but not OpenSuse. iirc this had the nice side effect of making all the timing related calls much more expensive, while not effecting accuracy of 1ms timing, which is what we are looking for and needing. > > On side note, its nice to see a freeswitch dev watching the list! I always read and hopefully chime in when the time is right. Mike
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
