Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

[George Anzinger <george@mvista.com>]

Roman Zippel wrote:
> Hi,
>
> On Tue, 11 Oct 2005, Thomas Gleixner wrote:
>
>
> > > > As far as I understand SUS timer resolution is equal to clock resolution
> > > > and the timer value/interval is rounded up to the resolution.
> > >
> > > Please check the rationale about clocks and timers. It talks about clocks 
> > > and timer services based on them and their resolutions can be different.

Well, yes and no.  Under timer_settime() it talks about ticks and resolution being the inverse of 
the tick rate.  AND it does imply that timers on a given CLOCK will have that clocks resolution as 
returned by clock_res().  This is fine as far as it goes.  In practical systems we almost always 
have a much higher resolution for the clock_gettime() and gettimeofday() than the tick rate.  What 
the standard does not seem to want to do is to admit that a clock may have the ability to be read at 
a better resolution than its tick rate.

For this reason, the usual practice is to return the "timer" resolution for clock_res() and to 
return clock values with as much resolution as possible.  In no case should the actual clock 
resolution be less than what clock_res() returns.

> > clock_settime():
> > ... Time values that are between two consecutive non-negative integer
> > multiples of the resolution of the specified clock shall be truncated
> > down to the smaller multiple of the resolution.
> >
> > timer_settime():
> > ...Time values that are between two consecutive non-negative integer
> > multiples of the resolution of the specified timer shall be rounded up
> > to the larger multiple of the resolution. Quantization error shall not
> > cause the timer to expire earlier than the rounded time value.

Here the standard uses "resolution of the specified timer" but the only way, in the standard, to 
associate a resolution with a timer is via the CLOCK used.
> Where does it say anything about that their resolution is equal?

So the timers resolution is the same as the CLOCKs resolution as returned by clock_res() but, as I 
said above, the usual practice is to return clock values (via clock_gettime or gettimeofday) with 
higher resolution.
> > > > Reprogramming interval timers by now + interval is completely wrong.
> > > > Reprogramming has to be 
> > > > timer->expires + interval and nothing else. 
> > >
> > > Where do get the requirement for an explicit rounding from?
> > > The point is that the timer should not expire early, but there is more 
> > > than one way to do this and can be done implicitly using the timer 
> > > resolution.
> >
> > See above.

The standard requires that timer expiry times and interval times be rounded up to the next 
"resolution" value.  For the first or initial time of a repeating timer we, usually, have to add an 
additional "resolution" to account for starting the timer at some point between ticks.  For the 
interval on repeating timers, we know that the interval is starting at the last expiry time and thus 
do not need to account for the between tick start time.
>
~

--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
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/