Re: Fw: missed itimer signals in 2.6

[Tom Marshall]

> >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().

Thanks again for taking the time to explain the timer system to me.

-- 
Never argue with an idiot.  They drag you down to their level, then beat you
with experience.

Attachment: pgp00001.pgp
Description: PGP signature