[ntp:questions] high jitter on serial gps causes big time offsets

Charles Elliott elliott.ch at verizon.net
Sat Apr 6 11:18:33 UTC 2013

I would test the local clock before relying on it for time.  In the bad old
days, around year 2000, when I first started processing SETI at Home (S at H) work
units (WUs), I could actually see that WUs were being processed faster in
the cool early morning hours than they were in the hot afternoons.  The
caveat is that an Intel tech support rep denied that that was possible.  In
any case, many others have commented on this list that the timing crystals
installed in typical motherboards vary significantly with temperature.  If
you price timing crystals with guaranteed accuracy you may well believe that
they don't install them in typical motherboards; they cost at least as much.

Charles Elliott

> -----Original Message-----
> From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On
> Behalf Of Robert Scott
> Sent: Friday, April 5, 2013 10:02 AM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] high jitter on serial gps causes big time
> offsets
> On Fri, 5 Apr 2013 11:09:29 GMT, Nickolay Orekhov <nowhere at mail.ru>
> wrote:
> >Hello!
> >I've got the following configuration:
> >
> >tos mindist 0.128
> >tinker panic 0 stepout 60
> >
> ># TSIP,PPS reference clock
> >
> >server mode 10 prefer maxpoll 3 true
> >fudge refid TSIP time1 0.08
> >
> >server maxpoll 3
> >fudge refid PPSI
> >
> >The main goal: I want 1 ms or better precision always, even with gps
> >quality going high and low.
> >
> >When satellites appear and disappear again, serial clock could be
> selected
> >before PPS clock. Or maybe some gps receivers will show good quality
> before
> >PPS will appear or will be selected.
> >
> >In general, I want ntpd to skip adjustments coming from specific
> server or
> >ref clock according to some constant precision. For example, I know
> that
> >gps serial jitter is about 30-40 ms. So I want ntpd to do no
> adjustments
> >lower than this value...
> I don't understand how this rule of not adjusting less than 30-40
> msec. offers any practical help to you.  You say you don't want to
> adjust by amounts less than this for fear of adjusting based on
> unreliable GPS serial timing.  But if you ever have to adjust by more
> than 30-40 msec., that is an admission that you were previously off by
> much more than your stated requirement of 1 msec. "always".  So the
> effect of this rule is to never adjust.  In short, you can't use the
> magnitude of the timing error to decide if the new GPS information is
> coming from the jittery serial data or from the PPS clock.  If you
> want to avoid using unreliable timing data you have to have some
> independent way of deciding if the data is unreliable.  I don't know
> enough about the indications from the GPS device to say how this is
> done, but it seems that the GPS device itself knows if it has valid
> PPS timing availble.
> If you want to maintain precision through low GPS quality periods you
> could fall back on your local clock, which hopefully has been
> rate-trimmed over a long period of time so its drift rate is small
> enough to maintain 1 msec. accuracy for as long as the GPS quality
> remains low.
> Robert Scott
> Hopkins, MN
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions

More information about the questions mailing list