Re: Strange dates with ntpd

[Frank Kardel <kardel%netbsd.org@localhost>]

On 08/30/12 08:58, Julian Coleman wrote:
> Hi,
>
> 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- 129.7.1.66       2 u   58   64  377  134.192   -2.756   0.121
>   *ntppub.le.ac.uk 140.203.204.77   2 u   28   64  377   27.818   -3.635   1.175
>   -anor.coris.org. 96.223.71.249    3 u   16   64  377    0.316  -19.739   0.221
>   +orthanc.coris.o 61.69.233.69     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 
> orion.coris.org.uk ntpdate 181 - - step time server 91.121.48.21 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).
>
> Thanks,
>
> J
>
> PS.  Real date was approximately Aug 30 07:26 BST at this point.
Frank