[time-nuts] TimeKeeper?

[Alexander Sack]

On Mon, Feb 22, 2010 at 5:03 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
>
>> That said NTP is very conservative in validating the stability of
>> clock sources. I have not delved into the code, but it is obvious
>> that even a refclock like a GPS receiver doesn't get any favours. Why
>> should it? Who knows whether the clock is dodgy or not?
>
> The NMEA strings from low cost GPS units have a lot of noise/jitter.
>
> In particular, the SiRF units are horrible.  (They are also low cost and
> widely available.)  The time offset has a sawtooth pattern with a long time
> constant that would be nasty to filter out.  Think of hanging bridges.
>  http://www.megapathdsl.net/~hmurray/ntp/GPSSiRF-off.gif
>
>
>> However the times he was reporting for the offsets to drop to less
>> than 1ms did look excessive.
>
> I've seen lots of comments about ntpd being slow to converge.  I haven't
> investigated carefully, but they seem credible.
>
> One way to get in trouble is to have a bad drift file.  You can get that if
> you have a warm system, shut it down, wait for it to cool off, then restart
> it.

I was not trying to start a fire and I personally don't have
experience with TimeKeeper which seems to be a framework to make use
of the TSC as we all would like to use it (despite P/C-state
invariants, there have been countless threads on all the major *NIX
kernel lists that have argued to use and not use TSC for ticking).

Bad drift files aside, I have now played around with both an Endrun
Technologies CDMA receiver as well as some other proprietary units and
I have found that no matter what ntpd reference drivers I used
(Palisade/Trimple come to mine), I have seen *many* instances of ntpd
doing wacky things and taking several hours to converge.  I never
really investigated why this was so and without looking at source code
attributed to ntpd doing exactly what you described Hal:  Using a very
conservative approach to validate the stability of the clock.

Also, TimeKeeper seems to predict time a bit if I understand what they
are doing (which I don't fully) while ntpd tries to skew toward
absolute time (UTC).

-aps