I think that's wrong: On the long term it doesn't make any difference, but while
adjusting time, the increase of time changes slope every second (i.e. time will
advance at different speed) when only adjusting the clock at the end of a second.
A frequency error should be corrected every time the clock is read. So you can
either do a correction frequently whenever it's needed ("tick interpolation"), or
you do it pro-active, even when it's not needed (That's what the
update_wall_time_one_tick() code does). In my solution I even tried to apply the
correction between ticks, using a combination of both methods.
What you are proposing is even what we had before, and much worse what can be
done. The old question: Do you want a fast clock, or an exact clock?
And who said that adjtime() isn't used by ntpd? "disable kernel" does exacltly
that I think.
As always I may be wrong...
On 11 Jan 2006 at 18:46, john stultz wrote:
> On Thu, 2005-12-22 at 00:25 +0100, Roman Zippel wrote:
> > This removes time_adjust from update_wall_time_one_tick() and moves it
> > to second_overflow() and adds it to tick_nsec_curr instead.
> > This slightly changes the adjtime() behaviour, instead of applying it to
> > the next tick, it's applied to the next second. As this interface isn't
> > used by ntp, there shouldn't be much users left.
> This sounds reasonable to me.
> Although CC'ing Ulrich and George for more review.
> Acked-by: John Stultz <[email protected]>
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Video 4 Linux]
[Linux for the blind]