[ntp:questions] Re: Netra X1 time warp

Roman Maeder maeder+news at mathconsult.ch
Sun Jan 25 13:45:43 UTC 2004


David L. Mills wrote:

> The system log shows no ntpd exit message. Once started, the only normal
> ntpd exit is accompanied by a message similar to that displayed by the
> second machine, and in that case the clock is not adjusted. Something
> stopped ntpd before it ever got to that point. The peerstats are
> recorded before the clock discipline routine is called. If the delta was
> found by ntpd, it would show up in the peerstats. I conclude ntpd either
> crashed and did not set the clock or was stopped by somebody else.

I did some investigation before I rebooted the machine. ntpd was still 
running, it served out time to anyone asking and it reacted to ntpdc and ntpq. 
"ntpq -p" showed nothing obviously wrong; it was as if it was running fine; is 
it possible that the clock discipline routine waited for a timer signal, that 
normally arrives every few seconds, but now would take 100years to be delivered?

The code that handles the DCF clock also kept running. I completely forgot 
about that log file. It shows the occasional "parse" error messages when a 
spike upsets the DCF77 receiver, but there is also something more interesting 
there:


22 Jan 03:49:15 ntpd[347]: synchronized to GENERIC(0), stratum=0
12 Jun 23:33:12 ntpd[347]: parse: convert_rawdcf: INCOMPLETE DATA - time code 
only has 29 bits

12 Jun 23:33:12 ntpd[347]: PARSE receiver #0: interval for following error 
message class is at least 00:01:00
12 Jun 23:33:12 ntpd[347]: PARSE receiver #0: FAILED TIMECODE: 
"------------------M-S---81-4" (check receiver configuration / cableling)
22 Jan 04:58:01 ntpd[347]: parse: convert_rawdcf: INCOMPLETE DATA - time code 
only has 33 bits

The first msg was before the problems started, it is in MET, then there are 
two with June dates (which year?) then the first of those dated January 22, 
1904 (MEST).
So I would conclude that the hiccup happened between 03:49:15 and 03:58:01, or 
02:49 and 02:58 UTC.

> Geeze I wish folks would keep the logs in UTC. The last peerstats was
> recorded at 0257 UTC on 53026 MJD, (22 January 2004 Gregorian). However,
> the second machine noticed the warp at 0432 MET or 1132 UTC. So, what
> was going on during the eight hours between 0257 and 1132? Did somebody
> kill ntpd near 0257 and then warp the clock near 1132?

0432 MET is 0332 UTC, so this is only a 35 minute gap. That seems to be the 
time ntpd allows to conclude that its server does indeed serve out wrong time 
consistently and that it's time to call it quits.


Roman Maeder




More information about the questions mailing list