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

From: Ulrich Windl (ulrich.windl_at_rz.uni-regensburg.de)
Date: 08/17/05

  • Next message: Avi Kivity: "Re: HDAPS, Need to park the head for real" 
    To: john stultz <johnstul@us.ibm.com>
Date:	Wed, 17 Aug 2005 09:40:37 +0200

    On 16 Aug 2005 at 18:17, john stultz wrote:

    [...]
    > 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

    One of the greatest mistakes in the past which still affects us now was the
    decision to piggy-back ntp_adjtime and ntp_gettime on top of adjtime() and thus
    creating adjtimex(). Only to save a system-call number or two. WE REALLY SHOULD
    GET RID OF THAT going back to Linux 0.something.

    > 2. Every tick we adjust those state values

    ... which require it.

    > 3. Every tick we use those values to make a nanosecond adjustment to
    > time.

    ...or even more frequent. In my code I tried to scale the tick interpolation as
    well, thus effectively making adjustments even within timer ticks (so far the
    theory...). I was assuming however that ticks and interpolation clocks are derived
    from one single source and would "float" the same way relative to each other.

    > 4. Those state values are otherwise unused.

    What is "otherwise"? Outside the "NTP clock model", or "between ticks"?

    >
    > Goals:
    > 1. Isolate NTP code to clean up the tick based timekeeping, reducing the
    > spaghetti-like code interactions.

    First you need a new clock model that's compatible with NTP. Then you can consider
    how to implement the NTP stuff. So the clock even without NTP has to be strictly
    monotonic for any interval it is read, be it nanoseconds, microseconds,
    milliseconds, seconds, minutes, hours, days, ... The clock delta (=increase of
    time) over time should be as constant as possible (i.e. time shouldn't go up like
    stairs).

    > 2. Add interfaces to allow for continuous, rather then tick based,
    > adjustments (much how ppc64 does currently, only shareable).

    Adjustments to the clock _model_ are asynchronous by definition, while adjustments
    to the clock itself are, well, periodic. Whatever the period.

    Maybe this helps and can be agreed on.

    Regards,
    Ulrich

    -
    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: Avi Kivity: "Re: HDAPS, Need to park the head for real"

    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: 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: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
      ... These values belong to the clock, NTP specifies the speed of the clock via ... Every tick we use those values to make a nanosecond adjustment to ... n cycles to speed up or slow down the system clock. ...
      (Linux-Kernel)
    • Re: Ktimer / -rt9 (+custom) monotonic_clock going backwards.
      ... NTP can slow down or speed up ... >> the clock, but it should never make it go backwards. ... than TICK_NSEC was added on a tick, AND, the time was read just prior to this tick the get_offset ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH/RFC 10/10] example of simple continuous gettimeofday
      ... Uses NTP to modify the clock frequency value rather then just ... > adjustment, which should be applied every f cycles. ... Your design seems to suggest keeping an NTP calculated reference time ...
      (Linux-Kernel)