On 02/21/14 01:52, Rob Janssen wrote:
Jeff Woolsey wrote:
On 02/20/14 12:21, Timothy Oefelein wrote:
One of the these days I'd like to get the hardware to run my own
Stratum 1 server, which would make the whole finding peers process
moot. :)
Not necessarily. Trust but verify your local reference clock against
other servers out there. For example, I'm currently seeing about
60ms of jitter/offset in the SHM refclock from gpsd managing a SiRF
II device. (It was 10 seconds off before I fixed gpsd not to request
messages it's ignoring anyway.). It's USB, but still I'd expect only
1-2ms of offset/jitter, which is fine for my purposes:
Using serial messages as a timesync (other than for determining the
time in seconds) is no good.
There is no good lock between the timing of the serial messages
relative to the real time value in them.
And when there is other traffic on the line, this becomes even more
apparent.
(not a 10 second difference though, you must have other issues!)
Serial message sources wandering around 60ms relative to the correct
time are quite common. Can be even more!
To have any value from a local GPS receiver, you need to use PPS.
This was easy in the days of RS232. I have a GPS module on a real
RS232 port (not USB) with PPS connected to DCD and timesync via gpsd.
It shows 0.001 in the jitter column. It would be even better with a
newer kernel that supports PPS in the kernel so it does not have to be
handled in the gpsd user process.
But GPS with only serial and no PPS - forget it. External sources on
a good internet connection will be better.
Rob
What we have here is an excellent example of the adage that all
generalizations are false. I am quite aware that PPS is necessary for
near-microsecond accuracy. It does bother me a bit, though, that some
such NTP servers out there have no other sources listed.
My objective was, and still is, to see how well I can do with no
additional outlay of funds, using GPS units that I already had about the
place or were purchased for other reasons. These are all consumer units
and do not have accessible PPS.
The SHM/gpsd setup I mentioned earlier is on a Raspberry Pi (Xmas gift)
using a Pharos 360 (SiRF II) on a Prolific serial-USB converter (both
from Microsoft Streets and Trips 2006, which came free from an estate).
gpsd puts it in SiRF binary mode instead of NMEA. (NTP doesn't have a
SiRF driver.) The initial 10-second offset was suspected to be
leap-second related (but it should be 16 seconds now). I managed to
eliminate it by adding code to gpsd to actually deselect a SiRF message
type that the comments said was being ignored. Now it wanders ~60ms and
I wonder if there's some issue with the SHM stuff. Old Pharos firmware
has certain problems and omissions (no UTC time, or PPS offset, for
example) in binary mode (paradoxically, NMEA here reports UTC to
millisecond precision (and no 10-second offset)) which may account for
this. gpsd advises against reflashing a SiRF. This is not my pool server.
Another example: A Garmin GPS V on a Keyspan USB serial port on a
PowerBook G4 running ntp. GPSy claimed that the device time was 0ms
behind the host. Hmmm. Very interesting. I gave it to ntp with the
generic NMEA driver and set the flag to use only the RMC sentence, and
got a consistent ~250ms offset. Fudged that and it's actually fairly
reasonable, in the 5ms offset region. Better than I expected from
NMEA. More about Garmins later. This also is not my pool server.
Quite some time ago I found an NTP refclock driver for the DeLorme
Tripmate, so I bought one on closeout. (Later I got another through
freecycle, but it's deaf.) The driver switches this unit to Rockwell
Zodiac (IIRC) binary mode. With a fudge value of 1.000 seconds, NTP is
consistently under 1ms of offset, the limiting factor here being the
real serial port strobe/sawtooth effect. That is about as good as a
real serial port at 9600bps can get. This is my pool server.
A similar long time ago (before the pool) I ran across an NTP refclock
driver for handheld Garmin GPS units. The driver puts them in GRMN
binary mode, not NMEA. For a particular model with specific firmware
versions, there is an oscillator offset counter to query which allows
NTP to achieve sub-millisecond accuracy. There may be other models that
work too, otherwise you only get sub-second accuracy. Again, the serial
port is the limiting factor. None of the Garmins I had at the time had
this counter available, alas. But the GPS V I mentioned was a later
acquisition and has not yet been tested, along with a 276C which I
actually use to navigate. The driver author had his NTP server
available, and I did see those sub-millisecond offsets.
===
Pretty much all of the GPS units I mentioned can be had for under $50
these days, as can some purpose-built bare timing receiver boards
(Encore, Jupiter, etc.). Tiny GPS boards for tiny microcontrollers are
similarly inexpensive, including a couple for the Raspberry Pi. All of
these have PPS available, and maybe someday I'll stick one on my Pi,
along with a WiFi dongle and solar power...
--
Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com
Spum bad keming.
Nature abhors a straight antenna, a clean lens, and unused storage capacity.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
"Card sorting, Joel." -me, re Solitaire
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
