lkml.org 
[lkml]   [2003]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fw: missed itimer signals in 2.6
Tom Marshall wrote:
>>>I expect there are at least a few applications that will misbehave because
>>>the developers did not expect a timer to behave this way (regardless of
>>>whether it's proper according to the spec).
>>>
>>>Is it possible to choose a timer resolution that errs on the high side of
>>>1ms instead of the low side? [*] It seems to me that would result in the
>>>application getting very close to the expected number of alarm signals. I
>>>am not at all familiar with the kernel design so I don't know if this would
>>>be feasible or not.
>>>
>>>[*] If this is the 8254 timer, using 1192 as a divisor should result in a
>>>resolution of ~1,000,686 nanoseconds.
>>
>>Well here is the rub. Your high side give an error of 686 PPM while the
>>low side has an error of only 152 PPM. This assumes, of course, that you
>>are trying to hit exactly 1,000,000 nano seconds per tick.
>>
>>On the other hand, since we do correct for this error, I suspect one could
>>use the high side number.
>
>
> It doesn't really matter to me, as an application developer, what the actual
> numbers are. What matters is that when I ask for a timer in the 1..50ms
> range, I get a reasonably close number of SIGALRMs to what I requested.
> Having to adjust the resolution by 9% at 10ms when I know the system clock
> is ticking at 10x that rate seems to be a bit broken from that perspective
> (not technically, but perceptually).
>
>
>>Still, if an application depends on the count rather than just reading the
>>clock, I suspect that some would consider it broken. Timer signals can be
>>delayed and may, in fact overrun with out notice (unlike POSIX timers which
>>tell you when they overrun).
>
>
> Our code does not depend solely on the delivery of SIGALRM. It resyncs
> periodically using gettimeofday().
>
>
>>What you really need is a higher resolution timer. Funny, there seems to
>>be a reference to such a thing in my signature :)
>
>
> I have rewritten our timer code to take the information learned in this
> thread into account. It turns out that at least one other *nix platform has
> problems with the magical 10ms number and, unlike the 2.6 kernel, does not
> seem to fill in the actual interval for getitimer().

That is the standard. They must be broken :(
>
> Thanks again for taking the time to explain the timer system to me.
>
You are very welcome.
--
George Anzinger george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.049 / U:0.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site