Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)

From: Roman Zippel (zippel_at_linux-m68k.org)
Date: 08/19/05

  • Next message: dean gaudet: "dying disk results in unusable system" 
    Date:	Fri, 19 Aug 2005 02:27:58 +0200 (CEST)
To: john stultz <johnstul@us.ibm.com>

    Hi,

    On Tue, 16 Aug 2005, john stultz wrote:

    > If they are private clock variables, why are they in the generic
    > timer.c? Everyone is using it in exactly the same way, no? Why do you
    > oppose having the adjustment and phase values behind an ntp_function()
    > interface?

    These values belong to the clock, NTP specifies the speed of the clock via
    tick/frequency, these variables specify the current state of the clock. If
    we assume there is only one system clock, we need only one set of those,
    so leaving them in timer.c doesn't really hurt. How these variables are
    updated depends on the clock, so separating them doesn't make much sense.

    > Maybe to focus this productively, I'll try to step back and outline the
    > goals at a high level and you can address those.
    >
    > My Assumptions:
    > 1. adjtimex() sets/gets NTP state values
    > 2. Every tick we adjust those state values
    > 3. Every tick we use those values to make a nanosecond adjustment to
    > time.
    > 4. Those state values are otherwise unused.
    >
    > Goals:
    > 1. Isolate NTP code to clean up the tick based timekeeping, reducing the
    > spaghetti-like code interactions.
    > 2. Add interfaces to allow for continuous, rather then tick based,
    > adjustments (much how ppc64 does currently, only shareable).

    Cleaning up the code would be nice, but that shouldn't be the priority
    right now, first we should get the math right.
    I looked a bit more on this aspect of your patch and I think it's overly
    complex even for continuous time sources. You can reduce the complexity
    by updating the clock in more regular intervals.

    What basically is needed to update in constant intervals (n cycles) a
    reference time controlled via NTP and the system time. The difference
    between those two can be used to adjust the cycle multiplier for the next
    n cycles to speed up or slow down the system clock.
    Calculating the offset in constant intervals makes the math a lot simpler,
    basically the current code is just a special case of that, where it
    directly updates the system time from the reference time at every tick.
    (In the end the differences between tick based and continuous sources may
    be even smaller than your current patches suggest. :) )

    bye, Roman
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: dean gaudet: "dying disk results in unusable system"

    Relevant Pages

    • Re: [RFC][PATCH] Experimental enhanced NTP error accounting patch
      ... The ntp code provides the time update per tick: ... That's all the clock code needs from the ntp code (the details of its ... To keep timeofday the same after changing the multiplier we also have to ...
      (Linux-Kernel)
    • Re: clock suddenly slipping behind
      ... >> over the past few days, i've noticed that my system clock gets about ... Uninstalling ntp and adjtimex and reinstalling didn't fix. ... hardware clock off a faulty software clock). ...
      (Debian-User)
    • Re: ntp
      ... If all you wanted was to read the system clock from a program. ... >> ntp device) with some set of private IP Address's like: ... connected to the NonStop USING a special driver. ...
      (comp.sys.tandem)
    • Re: Post processing of NTP data...
      ... One might measure the offset between the local system clock and UTC as the difference between the results of the gettimeofdayfunction executed on the local system and a 1 PPS signal standard. ... The offset measurement itself between an ntp system trained clock and the reference standard is a sum of the actual time error between the two clocks, the precision in which time is reported to the system OS by the hardware. ... The tick rate can generally be thought of as the system's metronome and limits the accuracy at which the system can report time. ... However I think OSes provide higher resolution time stamps, and I can only assume they interpolate between ticks with software. ...
      (comp.protocols.time.ntp)
    • Re: System clock
      ... The requirement is to run a separate clock by the NTP process, ... capability of system clock processing. ... processing in the user space program. ...
      (comp.protocols.time.ntp)