[lkml]   [2005]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH 2/2] Reduced NTP rework (part 2)

    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

    At 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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-10-10 14:41    [W:0.022 / U:47.084 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site