lists at cq.nu
Mon Feb 22 22:22:04 UTC 2010
If the objective is convergence to < 1 ms any timing optimized gps receiver
will do just fine. Non-timing receivers are going to do all sorts of bizarre
things every so often. I don't think we can blame this all on the GPS.
The NTP setup he's running in the article is broken. Setting the proper time
offset for the GPS you have is part of basic configuration. He alludes to
several other setup issues in his distribution. NTP is deliberately damped
when things are messed up.
Looking at the data, Timekeeper is going to do some really strange things
when varying asymmetric delays are involved. That's what NTP is trying to
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of Hal Murray
Sent: Monday, February 22, 2010 5:03 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] TimeKeeper?
> 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.
> 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
These are my opinions, not necessarily my employer's. I hate spam.
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to
and follow the instructions there.
More information about the time-nuts