Hal wrote:
>Here is a comment in refclock_process_f
> /*
> * Compute the timecode timestamp from the days, hours, minutes,
> * seconds and milliseconds/microseconds of the timecode. Use
> * clocktime() for the aggregate seconds and the msec/usec for
> * the fraction, when present. Note that this code relies on the
> * filesystem time for the years and does not use the years of
> * the timecode.
> */
>That doesn't sound right, but I haven't started pulling that string.
No? Well, I just did. Fsck...me...sideways! It's true. The reason
all those old, busted Y2K-afflicted refclocks worked is that ntpd
really does ignore the year part of clock timestamps.
A look at clocktime() is revealing, though you have to dig a little
deeper than that to realize what's actually going on. For clock
samples, the code (in effect) casts about for a year that puts the
sample within 4 hours of the packet receipt time...which means your
system clock has to be that approximately synced in order for a
refclock timestamp to be processed correctly at all.
There is one case where this really sucks. If you boot on a machine
with no access to remote clock peers, and the system time has been
thrown way off, it's going to try to conform its refclock samples to
whatever garbage value the system clock is holding. If it's zeroed,
you might get the "right" time of day within four hours of the Unix
epoch. I think.
There's an opportunity here. If the year were passed into clocktime,
it could check for a year > 99 and use it, freeing us of dependency on
the system clock in that case. Rather a boon for standalone operation
fed by a couple of refclocks.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
Good intentions will always be pleaded for every assumption of
authority. It is hardly too strong to say that the Constitution was
made to guard the people against the dangers of good intentions. There
are men in all ages who mean to govern well, but they mean to
govern. They promise to be good masters, but they mean to be masters.
-- Daniel Webster
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
