On May 14, 2010, at 2:50 PM, Matt White wrote: >>>> On 5/14/2010 at 02:26 PM, in message > <[email protected]>, Michael Jerris > <[email protected]> wrote: >> 250 means the timer is running less often not more often. Running with 250 >> will probably not work at all as we can not getting accurate enough timing. >> The places this comes into play are the places sipX uses freeswitch, when >> you >> are trying to send media from disk to a voip channel or when making a new >> stream such as in a conference we need to send it at a fairly stable rate as >> close to real as we can. There is quite a bit of play to be had here but if >> its wrong over time such as it builds up incorrectness over time this will >> be >> an issue. Expecting FreeSWITCH to fix an issue of not having accurate >> timing >> when the kernel config makes it impossible to get this timing is not really >> a >> realistic expectation. These applications simply require a timing source of >> at least some level of accuracy or they will not work. There is a plug-able >> timer interface available so you could come up with some hardware based >> timing that requires a driver and hardware support for someone who has a >> badly configured kernel, but this seems like the wrong approach to me. >> >> Mike >> > > My understanding and testing shows the freeswitch issue is not with the timer > running less, but running more. And the issue is not that Freeswitch can not > accurately get a timing source, but that it has an ton of short sleeps, and > in a tickless kernel the wakeup is honored rather than sleeping for time > based on the kernel timer. Disabling tickless and setting my timer to 2000 > has freeswitch at about 8% utilization without anything configured, 5% at > 1000hz and 1-2% at 250.
TImer running less will not cause cpu issues, it will cause audio issues. Have you tried a recent git build of FreeSWITCH? 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. > > 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. 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/
