[ntp:questions] nmea and initial large offset

Kalle Pokki kalle.pokki at iki.fi
Thu May 6 18:30:16 UTC 2010


On Thu, May 6, 2010 at 17:36, unruh <unruh at wormhole.physics.ubc.ca> wrote:
>
>> The funny thing is that the exact date is provided by e.g. the SHM
>> refclock driver, but the year information is intentionally discarded
>> when the timestamp propagates up towards the NTP core code. Then the
>> code does all kinds of heuristics to guess the correct year, but is
>> unable to do that if the clock is off by more than four hours.
>
> I do not understand this. The ntp timestamp provides the date as well as
> the time to ns. While the date has an ambiguity of soemthing like
> 100years, the assumption is that the century is the current one.

Yes, but reference clock drivers don't use the ntp timestamp. Take a
look at e.g. the SHM driver. There

1) In ntpd/refclock_shm.c function shm_poll() receives a time stamp
from the shared memory block. The timestamp includes the reference
clock time and the system time at the time of sampling. The time is
expressed as struct timeval, i.e. seconds and microsecods since 1970.

2) Still in shm_poll(), the time is converted into
   - day of year
   - hour
   - minute
   - seconds
   - nanoseconds
   Note that year is lost here.

3) In ntpd/ntp_refclock.c function refclock_process() feeds the
timestamp to the median filters. First it must, however, call

4) In libntp/clocktime.c function clocktime() that does all kinds of
guessing what the year might be. If the system time differs from the
sample (not counting the year) more than CLOSETIME (4 hours, that is)
the function gives up and decides that this is a bad sample and needs
to be discarded.

Nothing is logged in syslog. The reachability counter shown with the
"peer" command in ntpq shows no samples have been received from the
reference clock. There is no indication where the data is lost or why.




More information about the questions mailing list