Messages in this thread | | | Date | Wed, 15 Oct 2003 17:20:34 -0700 | From | George Anzinger <> | Subject | Re: 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/
| |