Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Strange dates with ntpd

On 08/30/12 08:58, Julian Coleman wrote:

Has anyone else seen ntpd not set the time correctly?  For example:

  # date
  Sat Apr 19 20:03:55 BST 10859
This is already a strange date to start with. It should be check why we get a date this far of after start-up - does the machine have a reasonably working real time clock ?

ntpd will is supposed to be designed to work at any time even though it uses 32-bit second time stamps. 2^32 seconds are roughly 136 years. The NTP time stamp (based in seconds since Jan 1st 1900) will wrap on 06:28:16 UTC on 7 Feb 2036 (Wikipedia). Ntpd will work if and only if the current time is within +-68 year of our 'official' time, The starting point you cited is a bit in the future and
ntpd locked onto that era of 136 year cycles.
Now rdate just transfers just the unix seconds value (also 32-bit). On 03:14:08 UTC on 19 January 2038
rdate will run into the wrap of its time stamp.

So to sum up. ntpd thinks is is right (but far in the wrong era of 136 year cycles). rdate currently works,
as is blindly transfers to corrects unix utc value.
The 640 ms difference you saw is the sub second difference (rdate has only second resolution).

The fix usually is to make sure that the current system time is within +- 68 years of the 'official' time.

So there is nothing wrong with ntpd, but the start value was not perfectly chosen.

when the peerings look OK:

  ntpq>  pe
       remote           refid      st t when poll reach   delay   offset  jitter
  +stratum-2-core-       2 u   58   64  377  134.192   -2.756   0.121
  *   2 u   28   64  377   27.818   -3.635   1.175    3 u   16   64  377    0.316  -19.739   0.221
  +orthanc.coris.o     3 u    6   64  377    0.365   -3.968   0.074

This is a sparc64 running 6.99.10.  I'd replaced the system board, so the
clock almost certainly contained the wrong time.  At startup, it ran ntpdate
before ntpd.  /var/log/messages contains:

   Apr 19 10:52:22 orion -: 10859-04-19T10:52:31.361110+01:00 ntpdate 181 - - step time server offset 
-0.316913 sec

I ran `rdate<remote>` while ntpq was still running, the time was set to
2012, and ntpd continued to run (it showed a jump in the offset (to 640ms)
and jitter for all the peers).



PS.  Real date was approximately Aug 30 07:26 BST at this point.


Home | Main Index | Thread Index | Old Index