[ntp:questions] NTP on red hat 7.3, was precision can be expected
david at ex.djwhome.demon.co.uk.invalid
Fri Jun 22 07:16:31 UTC 2007
In article <1182463059.180111.14500 at p77g2000hsh.googlegroups.com>,
Rejean <rsenecal at oerlikon.ca> wrote:
> > > If I compare the Linux Time with the GPS time using a oscilloscope.
How are you getting your oscilloscope signal from:
- the PC?
- the GPS receiver?
If you are using a PPS output on the receiver for this, why aren't you
feeding that to the PC?
Does ntpd even believe that the clock is valid?
What does ntpd think is the offset from the clock?
Is the PC's clock within the effective capture range for ntpd (i.e.
certainly no more than +/- 500ppm error and preferably no more than
> The GPS is connected through the serial port at 9600 bps
> And the ntp.conf is setup to read it.
What sort of serial port? (Simple UART on the PCI or ISA bus is good;
intelligent card or a USB port is bad.)
What protocol are you using to get the time from the GPS receiver?
Is the receiver intended for time transfer use (NMEA output on navigation
receivers can vary wildly in its timing relative to the true second)?
Is the receiver intended for time transfer use without PPS (many receivers
use the NMEA to establish the second, but expect the PPS output to be used
for anything more detailed than that)?
As already asked, what is the receiver?
Is the PC subject to power management changes in clock frequency?
With a good serial port input and no other problems, you should expect
an RMS error of around 1ms, or better, however we have no way of telling
whether your receiver can provide a serial port signal good enough for
that; most navigational GPS receivers cannot.
Note that, unless you are operating outside the altitude and velocity
limits built into commercial GPS receivers, using a military receiver will
not give you any benefit over a commercial receiver when used with serial
port input, and I doubt that there are many PCs which would benefit for
PPS input. (I suppose there may be military situations in which the L1
C/A signal is jammed or invalidated, but if you are working in that sort
of environment, you need to closely liase with the receiver's designers.
The re-introduction of selective availability wouldn't produce significant
errors within the capabilities of PC time keeping.)
More information about the questions