[time-nuts] My Palisade Issues resolved + Checking Stability and accuracy :)
hmurray at megapathdsl.net
Tue Sep 28 09:46:06 UTC 2010
> Just had to make a bit of a patch to the refclock_palisade.c driver, and
> send a character to the device, for hardware polling.. We suspect that
> perhaps my RS422 to RS232 adaptors might not set RTS or CTS high without
> data being present...
That seems pretty strange. Can you confirm it with a scope or meter?
I see that it sends a null in ACUTIME mode. Do you have a real Palisade or
> Here is my ntpq info -=- could anyone please have a bit of a look at the
> following and tell me if my ref_clock is working, and how accurate it it..
> and now how I can tell how 'stable' the clock is.
The peers display is has everything you need for a quick check.
remote refid st t when poll reach delay offset jitter
-warrane.connect 188.8.131.52 3 u 35 64 377 34.511 1.586 0.602
-caffeine.cc.com 184.108.40.206 3 u 30 64 377 64.355 -7.665 4.964
-pond.thecave.ws 220.127.116.11 2 u 27 64 377 85.675 -2.443 0.314
xns.creativecont 18.104.22.168 3 u 39 64 377 51.255 -23.593 13.578
-tur-dmz2.massey 22.214.171.124 2 u 28 64 377 15.298 0.769 0.500
+msltime.irl.cri .ATOM. 1 u 43 64 377 18.728 -1.113 0.389
+msltime2.irl.cr .ATOM. 1 u 5 64 377 18.158 -0.950 0.599
*GPS_PALISADE(0) .GPS. 0 l 13 16 377 0.000 0.306 0.056
The reach column is an octal bit mask of the last 8 times it tried to contact
that clock so your Palisade is working. (So are all the other servers.)
The * in column 1 means that it's the best clock: sys-peer. The x a couple
of lines up means that server is being ignored: it's too far off.
The offset and jitter look reasonable. They may get better if you wait a
while. (Units are ms.)
If you want lots of data, check out the statistics stuff. loopstats will
have what it thinks is the offset and the drift.
The 16 in the poll column means that it's grabbing data every 16 seconds. I
just took a quick ook at the source code. I think we can make it better. If
you are interested in helping debug it, contact me off list.
ntpd for refclocks is setup to collect a bunch of samples. Every polling
interval, it discards the outliers, and averages the remaining samples. It's
got a buffer of 64 slots so it works well with a poll interval of 64 if you
are collecting data every second, like PPS (ATOM) or NMEA. If I read the
Palisade code right, it's only grabbing one sample per polling interval. I
fixed the same problem in the shared-memory driver a while ago.
These are my opinions, not necessarily my employer's. I hate spam.
More information about the time-nuts