[ntp:questions] Running GPS under NTP

dhavey dhavey at gmail.com
Thu Dec 11 23:35:37 UTC 2008


On Dec 11, 1:59 pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
> dhavey <dha... at gmail.com> writes:
> >On Dec 10, 10:45 pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
> >> bruce.kl... at exfo.com (Bruce Kling) writes:
> >> >Hello,
>
> >> >I am currently running GPS as a separate process, independent of NTP and
> >> >I am able to achieve microsecond accuracy   If I run GPS under NTP as a
> >> >reference clock driver will this impact on the accuracy of time in any
> >> >way?  Thank you.
>
> >> Not sure what you mean. GPS is, in this context a hardware timing process.
> >> What do you mean "running GPS as a separate process"? You have a program
> >> which reads GPS, or which interrupts whent eh GPS PPS hits. How do you know
> >> you have "microsecond accuracy" and what has microsecond accuracy? And what
> >> does "impact the accuracy" mean?
>
> >> The GPS PPS can be used to discipline the local lock on a computer using
> >> ntp to a few microseconds standard deviation. I have a computer which does
> >> that. You can see the results onwww.theory.physics.ubc.ca/chrony/chrony.htmlandlook at string, which is a
> >> computer running ntp driven by the GPS PPS signal. As you can see the
> >> offsets tend to be around 3 usec. (mainly due to clock reading jitter, but
> >> also due to the reaction of ntp to thermal fluctuations of the computer.)
>
> >> (Mind you I have written a separate interrupt routine to read the clock on
> >> the parallel port interrupt, feeding the info to ntp via the shm refclock,
> >> so whether or not the various possible other refclocks do as well or better
> >> or worse I have no idea.
> >> )
> >This is interesting.  I am using shmpps and the NMEA patch for NTP
> >just like you describe.  I have four time servers connected to garmin
> >lvc stratum 0 devices.  Ntpq -p reports sub micro-second offsets which
> >is nice ;)
> >However, three of the time servers are connected to the fourth using
> >rs232 serial connections.  Each of the three stratum 1 time servers
> >runs the same program:
> >1. Wait for the begining of the next second.
> >2. Get the current timestamp.
> >3. Write the timestamp to the serial port.
> >The fourth time server runs three programs, one for each of it's
> >peers.  Each program does the same thing:
> >1. Wait to recieve data from the serial port.
> >2. Get the current timestamp.
> >3. Write both timestamps to a data log.
> >I am seeing 2000 - 4000 micro-second offsets from the serial port
> >experiments.
> >Here is a graph:
> >http://cs.ucsb.edu/~dhavey/gps/offset.pdf
> >I think I will connect a null modem cable between two serial ports on
> >one machine and measure the delay.
>
> AAArgh. Serial ports are horribly slow. Just calculate how long it takes to
> transfer your numbers over a serial line at say 9600Bd.
> That is why ntp works as it does. It sends out a time stamped packet, that
> packet is received by the server, and immediately time stamped. It is then
> timestamped again immediately before it is sent out again and finally time
> stamped by the client. If you assume that the packets have taken the same
> amount of time in transmission, the difference between the average time
> stamped by the client and those by the server is the best estimate of the
> true time difference between the two. If the two packets are exactly the
> same size ( and this is why the ntp packets are identical except for the
> contents of the registers) then the transmission times should be the same.
>
> >Any hints/ideas/suggestions?  Why so much offset?


Okay, my bad.  I just read what you said on the in the terrifyingly
incomplete ntp documentation.  I'll try the funny formula.

Alice is trying to find the PPS signal ;)
Chill

PS...I also tested the rs232 from ttyS1 to ttyS2 at 115200 and you are
right.  It is horibly slow.  Peace.




More information about the questions mailing list