[ntp:questions] Sure GPS - Very High Jitter and Offset

Ken Link klink at numberzero.org
Sat Aug 20 19:59:01 UTC 2011


If ntpd considers the PPS signal acceptable enough to mark it with an
'o', and the NMEA driver uses the PPS signal to "tidy up" the
timestamp received by the NMEA data (all from the same source), why
would ntpd think the NMEA data isn't good?

Maybe this screenshot will help explain: http://i.imgur.com/0oGCY.png

Based on the offsets in the picture, it looks like ntpd is
disciplining my clock as closely as possible to the GPS data. If it
were averaging the values of all the sources marked o, * and + I would
expect the offsets between those sources to be similar to each other
(+/- ~2ms probably). The way it looks now, it appears that ntpd isn't
doing anything with the source marked with *. I'm just confused as to
why it appears this way.

Perhaps I need to fudge my NMEA data with a time1 offset?

Ken

On Sat, Aug 20, 2011 at 1:32 PM, Chris Albertson
<albertson.chris at gmail.com> wrote:
>
>
> On Thu, Aug 18, 2011 at 11:16 AM, Ken Link <klink at numberzero.org> wrote:
>>
>> Question (hopefully last) about the behavior in this state. While
>> there is an 'o' next to the GPS clock, meaning it's the PPS peer, ntpd
>> also selects another peer with a '*' (the other peers are from the NTP
>> pool). Why does it select an additional peer? The only preferred peer
>> in ntp.conf is the GPS device. Shouldn't ntpd get the time AND pps
>> from the GPS clock?
>>
>> Running "ntpq -c assoc" shows the GPS clock as the pps.peer and the
>> pool source as sys.peer.
>
> ntpd computes the time from the set of ref. clocks that pass the clock
> selection criteria.   It is best to think of it that way rather than
> thinking it selects the "best" and syncs to it.  Rather ntpd selects an
> acceptable set of clocks,
> In your case it mmay be that the Sure GPS' NMEA data is not very god
> compared to the pool sever.
>
> --
>
> Chris Albertson
> Redondo Beach, California
>



More information about the questions mailing list