Re: clock problem

Martin Dieringer wrote:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*time 192.53.103.108 2 u 19 64 77 91.454 301.926 860.104

and the clock is "only" 3 seconds late now...

The delay, offset and jitter values are in milliseconds,
so your current offset is about 0.3 ms. When you keep
ntpd running, the offset should be reduced slowly.

ntpd calculates the drift of the local clock. During times
when it cannot reach the server, it corrects the local
clock using the recorded drift.

ok this sounds beautiful, but what if the drift is irregular?

Normal quartz-controlled hardware clocks don't have an
irregular drift. PC clocks aren't well-known for their
precision, but the drift should be fairly constant.

If your drift is noticeably irregular, then there is some-
thing very wrong with your machine. I'm afraid that ntpd
won't work very well under such circumstances.

In that case you'll have to find out the cause of the
problem and fix it, or help a FreeBSD to fix it (by
providing the necessary pieces of information).

But 2 minutes is also too much

ntpd should be able to handle that without problems.

yes maybe, sometimes...

Well, I agree that 2 minutes per day is much. Normally
the maximum drift that can be corrected by "slewing" the
clock is about 45 seconds per day (500 ppm). However,
if the offset is larger than a certain limit, ntpd will
step the clock anyway, so even a drift of 2 minutes
should be correctable. (I think the limit is 128 ms,
and the step will occur if the limit is exceeded for at
least 15 minutes. But I'd have to look at the source
code to be sure; the manual pages are sometimes not up-
to-date with regard to such details.)

I have to redialup every 24h which normally works fine.

How are you redialling? If you get a new dynamic IP
address, it might be necessary to restart ntpd.
MYADDR:
!bg /etc/rc.d/ntpd restart

great! 8-(
as "restart" does not work because the pid seems to be wrong and
usually there are 5 or so ntpd's running... ?

Hu? There should be exactly one ntpd process running.
You should clean up (kill all of them, remove any bogus
PID file if there's one left, then restart ntpd).

btw, this is on the other machine which is now 2 minutes off again,
maybe 1 hour after correct setting:

# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
chronos.zedat.f .PPS. 1 u 457 512 377 366.965 37369.6 8640.85

log:
8 May 16:11:08 ntpd[57617]: synchronized to 130.133.1.10, stratum=1
8 May 16:11:08 ntpd[57617]: time reset +0.651381 s
8 May 16:11:08 ntpd[57617]: kernel time sync disabled 2041
8 May 16:12:22 ntpd[57617]: synchronized to 130.133.1.10, stratum=1
8 May 16:13:30 ntpd[57617]: no servers reachable

now: 16:57

A jitter of 8 seconds is really a lot. Is your uplink
that bad? Of course, that adds to the problem that you
already have because of (supposedly) irregular drift.

If you have multiple machines behind the same uplink, it
might be a good idea to configure one of them as an NTP
server (preferably the one which has the smallest drift),
and let all your other machines use that machine as the
NTP time source. So at least all your own machines are
synchronized with each other, and you separate the problem
of the drift from the problem of a bad uplink.

Best regards
Oliver

--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd

"One of the main causes of the fall of the Roman Empire was that,
lacking zero, they had no way to indicate successful termination
of their C programs."
-- Robert Firth
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Isolated Network Drift Problem
    ... If the computer time is fast you need to slow down the computer clock. ... offset for you and correct your clock. ... And if you want to correct that drift youhave to give ... Aside from a kernel parameter entry in /etc/sysctl.conf the ...
    (comp.protocols.time.ntp)
  • Re: Choice of local reference clock seems to affect synchronization on a leaf node
    ... You have a broken interpretation on how the NTP discipline algorithm ... My own experiments with chrony and ntpd with a network ... With the aggressive elimination of measurements by the clock filter ... Starting NTP weith an initial ten-year offset is not a frequent ...
    (comp.protocols.time.ntp)
  • Re: ntpd -q and driftfile
    ... into ntpd-- one time setting of the clock time. ... If he wants a drift file then as you say, ... which is what ntpd is designed for. ...
    (comp.protocols.time.ntp)
  • Re: ntpd -q and driftfile
    ... into ntpd-- one time setting of the clock time. ... If he wants a drift file then as you say, ... which is what ntpd is designed for. ...
    (comp.protocols.time.ntp)
  • Re: Strange scattergram
    ... wedge scattergrams were used. ... Your system clock runs fast and ... ntpd adjusts it back in what look to me to be about a two hour cycle. ... offset is always very small, ...
    (comp.protocols.time.ntp)