microuptime() went backwards

[Danny MacMillan]

On Fri, 23 Apr 2004 13:41:18 +0100, Matthew Seaman 
<m.seaman at infracaninophile.co.uk> wrote:

> On Fri, Apr 23, 2004 at 01:13:11PM +0100, Jez Hancock wrote:
>> On Fri, Apr 23, 2004 at 09:04:56AM +0300, hugle wrote:
>>
>> > SOmetimes I see such messages in dmesg.
>> >
>> > perl# dmesg
>> > uptime() went backwards (1574174.333073 -> 1573478.944788)
>> >
>> > what they mean? and what causes them to appear ?
>> > is it good or bad?? :)
>>
>> I'd always presumed these messages occured on my machine because the
>> ntpd (network time protocol daemon) had adjusted the system clock.  I
>> can't actually tell you for sure since the messages aren't logged by
>> syslog here so there's no easy way of comparing the times to see if they
>> correspond to the ntpd adjustments.

ntpd can be configured to maintain a log file and does, if I recall 
correctly, log a warning messages each time it is forced to step rather 
than slew the time (see below).

>> Check to see if you have ntpd running - if so that's probably the reason
>> for the messages.
>
> Actually, that shouldn't happen because of ntpd(8).  If ntpd detects
> that your system clock is fast, it will make it run slightly slower
> until it gradually comes back into synch.  It shouldn't ever jump the
> system clock to the right time during normal operation, neither should
> it ever cause the system clock to run backwards.

A partial excerpt from man ntpd(8):

      -x      Normally, the time is slewed if the offset is less than the 
step
              threshold, which is 128 ms by default, and stepped if above 
the
              threshold.  This option forces the time to be slewed in all
              cases.  If the step threshold is set to zero, all offsets are
              stepped, regardless of value and regardless of the -x 
option.  In
              general, this is not a good idea, as it bypasses the clock 
state
              machine which is designed to cope with large time and 
frequency
              errors Note: Since the slew rate is limited to 0.5 ms/s, each
              second of adjustment requires an amortization interval of 
2000 s.
              Thus, an adjustment of many seconds can take hours or days to
              amortize.  This option can be used with the -q option.

     How NTP Operates

     ...

     As the result of this behavior, once the clock has been set, it very
     rarely strays more than 128 ms, even under extreme cases of network 
path
     congestion and jitter.  Sometimes, in particular when ntpd is first
     started, the error might exceed 128 ms.  This may on occasion cause the
     clock to be set backwards if the local clock time is more than 128 s in
     the future relative to the server.

-Danny