[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