[Asterisk-Dev] High resolution timers using POSIX clocks instead of zaptel

[Steven]

On Tue, 2005-06-07 at 13:00 -0400, Steve Kann wrote:
> Steven wrote:
> 
> >On Tue, 2005-06-07 at 12:16 -0400, Steve Kann wrote:
> >  
> >
> >>Gilad Ben-Yossef wrote:
> >>>Derek Smithies wrote:
> >>>>Does anyone have some realworld experience on a recent machine & 
> >>>>software timers to prove they are still a bad idea?
> >>>Fact of life - on a 2.4 Linux kernel for x86 or PPC the timer 
> >>>resolution is 10ms (look for the HZ macro in 
> >>>/usr/src/linux/include/asm/param.h) That's simply not enough.
> >>Not enough for what?  What do you need to do that 10ms resultion isn't 
> >>enough?
> >
> >I'm betting that since 10ms is equal to 80 samples, that you would see
> >that it is too slow for the current needs. To slow down to a 10ms
> >resolution would might require 2 sets of timer routines, one able to
> >handle the zapata resolution and then the software timer one.
> >
> What current needs?  I mean, what are these hardware timers used for:
> 
> meetme:  The processing frequency here approximately equals the extra 
> delay introduced.  You can easily run meetme conferences 50 times per 
> second, instead of 1000 times per second.
> 
> iax trunking:  Since the trunk frames only go out every 20ms or whatever 
> you've set, clearly you don't need a 1ms timer driving them. 
> 
> generators (for playing sounds, etc):  Since these things are being used 
> only when you're doing VoIP, you certainly don't need 1ms resolution for 
> them.

My concern is in the changes that would occur to handle the longer
times. A great deal of us have hardware generating the 1ms interupts.
Should the method be adaptive so we continue to have the best possible
quality or do you suggest we go backwards in quality to meet the slower
software timers the VoIP only users have. 

One has complexity that may or may not be a problem. The other degrades
a bit what we have already.
-- 
Steven <critch at basesys.com>