On Thu, May 6, 2010 at 17:36, unruh <[email protected]> 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. _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
