On Fri, 23 Apr 2004 13:41:18 +0100, Matthew Seaman <[EMAIL PROTECTED]> 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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to