I already gave you the necessary details for how to set
NTP_INTERVAL_LENGTH and in the previous mail I explained the basis for it.
I really don't understand what's your problem with it. Why do you try to
make it more complex than necessary?
You don't create consistency by adding corrections all over the place
until it adds up to the right sum.
The current correction is already somewhat of a hack and I'd rather get
rid of it than to let it spread all over the place (it's really only
needed so that people with weird HZ settings don't hit the 500ppm limit
and we're basically cheating to the ntpd by not telling it the real
frequency). Please keep the knowledge about this crutch at a single place
and don't spread it.
Anyway, for NO_HZ this correction is completely irrelevant, so again
there's no point in adding random values all over the place until you get
the correct result.
The only other alternative would be to calculate this correction
dynamically. For this you leave NTP_INTERVAL_LENGTH as is and when
changing clocks you check whether "abs(((cs->xtime_interval *
NTP_INTERVAL_FREQ) >> cs->shift) - NSEC_PER_SEC)" exceeds a certain limit
(e.g. 200usec) and in this case you print a warning message, that the
clock has large base drift value and is a bad ntp source and apply a
correction value. This way the correction only hits the very few system
which might need it and it would be the prefered solution, but it also
requires a few more changes.
bye, Roman
--
