Date: Fri, 23 Apr 2004 16:13:44 -0600 From: Danny MacMillan <flowers@users.sourceforge.net> To: Matthew Seaman <m.seaman@infracaninophile.co.uk>, hugle <hugle@vkt.lt>, freebsd-questions@freebsd.org Subject: Re: microuptime() went backwards Message-ID: <opr6xj06b8rcgix0@shawmail> In-Reply-To: <20040423124118.GA20775@happy-idiot-talk.infracaninophile.co.uk> References: <159171051438.20040423090456@vkt.lt> <20040423121311.GB41702@munk.nu> <20040423124118.GA20775@happy-idiot-talk.infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 23 Apr 2004 13:41:18 +0100, Matthew Seaman
<m.seaman@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opr6xj06b8rcgix0>