[ntp:questions] PSYCHO PC clock is advancing at 2 HR per second

David J Taylor david-taylor at blueyonder.co.uk.invalid
Tue Mar 20 15:21:13 UTC 2012

"Ron Frazier (NTP)" <timekeepingntplist at c3energy.com> wrote in message
> Hypothetically speaking, what if I don't want it to distribute time if 
> it's working in internet mode?

Run a Perl script one a minute, looking for the GPS line in ntpq -p 
output, and if the tally code isn't "*" (or whatever, get it to run:

  "net stop ntp"

> Non time server machines
>    GPS (if attached)
>    Local time server (if available)
>    Internet as backup
> However, I only plan to do that after thoroughly testing the GPS by 
> itself for a week or two to see if it's stable.  I originally had the 
> internet servers on with this unit.  It completely surprised me by 
> having this tendency to drift apparently and have periodic heart 
> attacks.

It's not a time GPS, so one could argue that it's not to be trusted.

> Unfortunately, this odd behavior may exist in all SIRF III and possibly 
> other SIRF units.

Unlikely, as there are several GPS receivers with PPS outputs listed using 
that chipset.

> It was only by turning off the internet servers that I was able to get 
> some clean graphs of exactly what the GPS was doing.  When I had the 
> internet servers enabled, once the GPS starting acting odd, which it 
> shouldn't do at all, NTPD would clock hop to the internet.  Normally, 
> that would be OK.  However, as discussed previously, even my errant GPS 
> is more accurate over the short term than the internet for me.  With the 
> internet conection, I get + / - 50 ms variations in time over a span of 
> an our.  With the GPS, I get + / - 60 ms variations over several days, 
> with a few wild corrections during its heart attacks.  Those are two bad 
> choices, but I think I'd still rather run on the GPS.

Your choice, of course.

> The only way I can prevent clock hopping is by noselecting the internet 
> servers.

What's the problem with the clock changing to Internet servers?  It will 
change back again when the GPS returns to an acceptable state.

> Even if I end up with internet servers turned on, which I expect to, I 
> think it's much better to know about these GPS anomalies before putting 
> it into long term service.  Anybody considering using a SIRF III or 
> maybe even any SIRF unit for timekeeping should be warned by my 
> experience, test the unit, and make sure it's up to the task.  These 
> problems could even affect SIRF units with PPS outputs, although I don't 
> know.  I'll probably decommission this unit from timekeeping duty and 
> relegate it to navigation duty, although I'm not sure how trustworthy it 
> is for that when it's throwing a temper tantrum.

You want to say all SiRF chipsets are bad on the basis of testing one 
manufacturer's implementation, and in a way which the software supplier 
doesn't recommend?

> I've already committed to getting better (hopefully) equipment. 
> (Shipping from Hong Kong or where ever seems to take a LONG time when 
> you're waiting on something.)

2-3 weeks, and I'm an impatient sort as well!  <G>

>  Hopefully, the Sure board will be much more stable and reliable.  I'm 
> planning to do the same extensive testing on the Sure for a week or two. 
> I'll start out just plugging the Sure into my serial - USB converter 
> using the same com port as the Globalsat unit was running on.  I want to 
> see how it does with NMEA only data for a while.  I'm hoping NOT to see 
> substantial drifting from UTC and NOT to see any heart attacks every few 
> days.  I expect lots of jitter, since a number of variable length 
> sentences are being output.  Then, I plan to turn off all but GPGGA and 
> test some more, and maybe tinker with the baud rate.  Then, if I can 
> solder the board without killing it, I'll engage PPS through the 
> serial - USB port and test that for a while.  Then, I'll try it with PPS 
> and real serial on my other computer, the only one with a serial port.

You /will/ see variation in the serial output from the Sure device, as you 
will in many NMEA devices.  For the Sure device, one measurement is here:


under the heading "NMEA Latency".  The graph here is 100 milliseconds full 


> Hopefully, when I'm done, I'll have a qualified unit running stably and 
> accurately for the whole network to use.  I've acquired a case and some 
> hardware to mount the device similar to yours.  Once I learned that it 
> was only 3" x 3", that made me nervous as far as soldering and all, but 
> we'll see what happens.

If in doubt, find someone who is used to working on such units.  You could 
try Bill Unruh's suggestion to start with.

> By the way, do you think I should update to Dave H's latest binaries? 
> I'm at 4.2.7p259 on Windows.  Almost all these discussions have been 
> about Windows.  Linux is a whole other ballgame.  The NTPD there from 
> the repositories is about 2 years old, and I'm reluctant to go outside 
> the repositories because of the numerous problems it creates.  One very 
> serious Linux user on a local message board said even he doesn't compile 
> his own programs because of possible problems.  I tried it once and all 
> sorts of scripts and file locations that Ubuntu expects got broken.
> Sincerely,
> Ron

You will find my current versions listed here.  ntpd 4.2.7p263 seems to be 
working fine, including on Windows-8.  Whilst it was more complicated than 
I would have wished, and took a lot longer, I did mange to use the FreeBSD 

  portmaster net/ntp-devel

I expect there's something similar for Linux.  You compile to a local 
directory and copy the executables to the working directory, just like on 


More information about the questions mailing list