Re: Running GPS under NTP
- From: Unruh <unruh-spam@xxxxxxxxxxxxxx>
- Date: Thu, 11 Dec 2008 21:59:01 GMT
dhavey <dhavey@xxxxxxxxx> writes:
On Dec 10, 10:45 pm, Unruh <unruh-s...@xxxxxxxxxxxxxx> wrote:
bruce.kl...@xxxxxxxx (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.htmland look 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?.
- Follow-Ups:
- Re: Running GPS under NTP
- From: dhavey
- Re: Running GPS under NTP
- References:
- Running GPS under NTP
- From: Bruce Kling
- Re: Running GPS under NTP
- From: Unruh
- Re: Running GPS under NTP
- From: dhavey
- Running GPS under NTP
- Prev by Date: Re: how to write a reference clock driver
- Next by Date: Re: Should ntpd log failure to syslog?
- Previous by thread: Re: Running GPS under NTP
- Next by thread: Re: Running GPS under NTP
- Index(es):
Relevant Pages
|
