[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
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
> 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
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
> 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.
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
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