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

Steve Kann stevek at stevek.com
Tue Jun 7 10:54:18 MST 2005


Steve Underwood 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.
>>  
>>
> I think the only thing is common use with * that doesn't work in 
> multiples of 10ms is LPC10. Why is <10ms resolution important.

Ok, set aside from the fact that I don't imagine anyone cares about 
LPC-10 -- but, so what? 

If things are designed well, and you have 100ms of buffering ability on 
inputs, you can do everything you need to with a 100ms timer;  Just 
process whatever is there at the time.

For example, if you have generators generating audio to be sent via 
VoIP, then you just do it like this:

time 0: send nothing.
time 100, send frames 0, 20, 40, 60, 80.
time 200, send frames 100, 120, 140, 160, 180
...

Same thing for conferencing, etc.

There's some more latency involved in using a longer timer length, but 
there's also a lot more efficiency, not just from reducing context 
switches, but also from cache locality, etc.

-SteveK






More information about the asterisk-dev mailing list