Hi,
On Thu, 29 Sep 2005, john stultz wrote:
> timekeeping_periodic_hook():
> now = timesource_read(ts)
> delta_cycle = now - last
> while (delta_cycle > interval_cycle):
> delta_cycle -= interval_cycle
> system_time += interval_nsec
> ntp_advance(interval_nsec)
I'm concerned about the clock stability of your code. By rounding it to
nsec you throwing away a few bits of resolution (unless I'm missing
something).
At http://www.xs4all.nl/~zippel/ntp/ there are a few patches to cleanup
the kernel ntp calculations. I extracted the first two patches from your
patches, the other patches precompute as much as possible so that the
interrupt functions become quite simple and also fix a few rounding
problems. What might be useful for you how second_overflow() calculates
the advancement for the next HZ ticks. This means ntp_advance() isn't
really needed at all, but instead second_overflow() precalculates
everything for next second.
(The patches aren't documented yet and only for 2.6.13, I'll fix this
soon).
I also included the modification for old ntp reference implementation to
match this behaviour, so I could verify and test my changes in a
simulator. I'd really like to have something like this for your
implementation, so it's easier to look at its behaviour.
I started looking through the nanokernel implementation to see how it can
be applied to Linux.
> > The basic idea of gettimeofday is of course always the same: "base +
> > get_offset() * mult". I can understand the temptation to unify the
> > implementation, but please accept the current reality that we have
> > different gettimeofday implementations (for whatever reasons), so unifying
> > them would be a premature change. If the situation changes later we can
> > still do that unification.
>
> I'm sorta going at it from the other way (call me optimistic :), where
> I'm trying to unify what I can until I hit the exception. Then I'll
> happily break out an arch specific gettimeofday implementation.
That's fine as long as doesn't change too much, but OTOH a little code
duplication doesn't hurt. Concentration on introducing the time source
abstraction is IMO currently more important, having more than one ntp
implemenation is not such a big problem during development, so the need
for a config option disappears and people can quickly switch between
implementations, if there should be a problem.
In the end we actually may have slightly different NTP implementations, as
each timesource may have different requirements of what needs to be
precalculated for an efficient timer implementation. The unification
should really be the last step, first we need to get the basic stuff
right, then we can look at what can and should be optimized and only then
should we cleanup the common things.
bye, Roman
-
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]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
