Re: Ktimer / -rt9 (+custom) monotonic_clock going backwards.

From: George Anzinger (george_at_mvista.com)
Date: 10/21/05

  • Next message: Grant Coady: "Re: 2.6.13.4: 'find' complained about sysfs"
    Date:	Thu, 20 Oct 2005 15:19:29 -0700
    To: Daniel Walker <dwalker@mvista.com>
    
    

    Daniel Walker wrote:
    > On Thu, 20 Oct 2005, Steven Rostedt wrote:
    >
    >>
    >> Yes, but that shouldn't make a difference. NTP can slow down or speed up
    >> the clock, but it should never make it go backwards. Especially for a
    >> monotonic clock (as the name suggests).
    >
    >
    > It looks like if ntp_adj held a big negative number you might end up
    > with a smaller output . ntp_adj is signed too .. I don't know how
    > ntp_adj is set though .
    >
    > I thought I remember George Anzinger speculating that ntp could
    > cause the time to backwards , that's why I brought it up. Maybe if he's
    > read he can clue us in ..
    >
    I think John has changed this, but in the "old" code if ntp was correcting the clock such that less
    than TICK_NSEC was added on a tick, AND, the time was read just prior to this tick the get_offset
    code would return ~TICK_NSEC of offset which would mean that a read right after the tick might be
    less than the one just prior to the tick. The error, however, would be in the nanosecond area (no
    where near a second). Again, as I said, I think John has changed this in is code so that the
    get_offset equivalent is also ntp corrected, thus eliminating the small back step.
    >

    -- 
    George Anzinger   george@mvista.com
    HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
    -
    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: Grant Coady: "Re: 2.6.13.4: 'find' complained about sysfs"

    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: [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)
    • 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: ntp discipline of local time?
      ... Principles and Precision Time Synchronization briefings on the NTP project page are old but applicable. ... The details you are asking for are carefully explained in the NTPv4 spec. ... like the clock state machine and poll-adjust algorithm continue in the daemon. ... factor from CPU cycles to time) and get rid of the offset. ...
      (comp.protocols.time.ntp)