[ntp:questions] PSYCHO PC clock is advancing at 2 HR per second
Ron Frazier (NTP)
timekeepingntplist at c3energy.com
Wed Mar 21 00:35:33 UTC 2012
On 3/20/2012 11:21 AM, David J Taylor wrote:
> "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 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.
While I'm testing to determine the GPS's stability and reliability, I
don't want it clock hopping. It screws up my graphs. Once I'm
satisfied with the system and revert to normal operating mode, I don't
have a problem with it.
>> 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?
There are two issues, the NMEA drift, and the periodic heart attacks. I
know from Charles Elliott's (I think) comments that his BU-353 exhibits
both curses. So, I'd say it's intrinsic to that product, at least. I
don't know if other Globalsat products do these things. I've got
reports of other SIRF based devices showing the substantial NMEA drift.
I don't know if they are subject to the heart attacks or offset storms
that this unit exhibits. You can bet I'd want to test ANY other SIRF
designs before deploying it.
>> 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 scale.
That's funny, there's this line in the text.
"In a 15 minute run (900 seconds) the mean latency was 350.2 ms with a
standard deviation (jitter) of 10.7 ms. "
Then there's the graph, which seems to show a variance in NMEA start
time of 75 ms or so. The two seem to contradict each other.
You already mentioned the Garmin previously, and the Sure now, and I
have reports of similar NMEA drifting behavior from other SIRF units.
So, it appears that most, if not all GPS's exhibit a variance in the
timing of NMEA data of 50 to 120 ms or so. That would definitely put a
limit on what you could do with NMEA only data.
>> 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 command:
> 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 Windows.
I think I'll update my Windows binaries. I still haven't decided what
to do with Linux.
(PS - If you email me and don't get a quick response, don't be concerned.
I get about 300 emails per day from alternate energy mailing lists and
such. I don't always see new messages very quickly. If you need a
reply and have not heard from me in 1 - 2 weeks, send your message again.)
timekeepingdude AT c3energy.com
More information about the questions