> > I think "lowerbound <= usec < upper_bound" would have been enough,
> > but:
>
> That's what my first patch looked like. Then ...
>
> > If you remember that tick can be adjusted (maybe to 9999), you can
> > have the additional problem tha tthe interval is still too small.
> > What about replacing "(tick / 2)" with "((tick + 1) / 2)". (gcc
> > shouldn't care about ">> 1" or "/ 2" if the number is unsigned...)
>
> ... I also noticed the case of odd values for tick. I also thought
> about (tick+1)/2 which is somewhat cleaner, since it doesn't make the
> intervall one larger than neccessary in case of even tick. But in the
> end I found lbound <= usec <= ubound more symmetrical and prefered
> that. Doesn't matter that much, however.
>
> But one should consider (tick + tickadj)/2 instead of tick/2, as
> otherwise it could still happen that the RTC is not set (or was it
> time_adj instead of tickadj?)
Using "tick + tickadj" would mean that (remember that tickadj is
always positive) the CMOS clock is updated when an adjtime() is in
effect. I'd consider that as a bad idea. OTOH if the kernel PLL is
actively correcting the frequency, the tick is corrected most of the
time. I guess you are right then.
Possibly the thing you meant is "time_adjust_step".
So we have "(tick + time_adjust_step + 1) / 2" and we hope that gcc's
CSE (common subexpression elimination) works when comparing ;-)
Well: a final remark: This does not only affect i386 architectures...
Ulrich