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@Home (S@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....@lists.ntp.org > [mailto:questions-bounces+elliott.ch=verizon....@lists.ntp.org] On > Behalf Of Robert Scott > Sent: Friday, April 5, 2013 10:02 AM > To: questions@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 <nowh...@mail.ru> > wrote: > > >Hello! > >I've got the following configuration: > > > >tos mindist 0.128 > >tinker panic 0 stepout 60 > > > ># TSIP,PPS reference clock > > > >server 127.127.8.0 mode 10 prefer maxpoll 3 true > >fudge 127.127.8.0 refid TSIP time1 0.08 > > > >server 127.127.22.0 maxpoll 3 > >fudge 127.127.22.0 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@lists.ntp.org > http://lists.ntp.org/listinfo/questions _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
