clock problem

[Oliver Fromme]

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