[ntp:questions] Re: GPS, IEEE 1344, and NTP - a field report
JoeGwinn at comcast.net
Mon Jun 20 12:46:11 UTC 2005
In article <kuhio2-6pt.ln1 at gateway.py.meinberg.de>,
Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> Joseph Gwinn wrote:
> > In a system I'm involved with, we had a field failure, when time in the
> > computers fed by a NTP time server fell out of bed at the turn of the
> > year.
> > The problem was traced to a misconfigured NTP time server that was
> > ignoring the 1344 data (which contains the Gregorian year) in the IRIG-B
> > signal from the GPS receiver. Vanilla IRIG-B carries only the number of
> > the day (0-365) within the current year, but doesn't tell you which year
> > it is.
> Yes, and if the current year is a leap year, then Feb 29 has the same
> day-of-year number as March 1 in non-leap years. That one day offset rests
> until the end of the leap year.
> If the routine which converts day-of-year back to date-of-year doesn't know
> about or account for a year being a leap year then the conversion returns
> faulty results.
Yep. Problem didn't appear then because the sysadmin had manually set
the year correctly.
> The knowledge of the year number can be derived from the IEEE1344 data in
> the IRIG code, if that is available, or it could be derived from the date
> of the target system, which assumes that the system date has been
> initialized properly.
> Did the NTP time server have a built-in IRIG decoder card, or was the IRIG
> code fed to ntpd using the audio driver? If using the audio driver, which
> version of NTP has been running?
The year was supposed to come via 1344 data, and the target system was
not supposed to add its two cents worth.
The NTP timeserver has its own IRIG card, and no audio driver is
PS. Harlan Stenn asked me to write a NTP FAQ on this problem, and I am
in the process of collecting the various details to do that.
More information about the questions