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

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:
>  http://www.leapsecond.com/pages/MG1613S/
> under the heading "NMEA Latency".  The graph here is 100 milliseconds 
> full scale.
>  http://www.leapsecond.com/pages/MG1613S/nmea-jitter-1.gif

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.
>> 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 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.
> Cheers,
> David

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

Ron Frazier
timekeepingdude AT c3energy.com

More information about the questions mailing list