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 On May 14, 2010, at 2:08 PM, Matt White wrote: > I was working on the suse builds and ran across a freeswitch issue with > utilization in the 10-20% range when idle. This thread explains it well > http://old.nabble.com/FreeSWITCH-under-the-Linux-2.6.29-kernel-td23248559.html > > It ended up being an issue with the tickless kernel support in newer > kernels...disabling it brought idle utilization to a constant 2%.... I still > think its an issue freeswitch should needs to fix but for now have a work > around. > > But that got me thinking, Centos 5.x sets the timer at 1000hz and SLE 11.x at > 250hz. Doing some reading would suggest that 1000 might be pushing it for > real-time apps like RTP. Freeswitch throws a warning for anything greater > than 1000. > > Has there been any research done on how kernel timers affect sipx? If I have > to set the timer in the suse builds I want to set it to something optimal. >
_______________________________________________ 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/
