[time-nuts] My Palisade Issues resolved + Checking Stability and accuracy :)

[Hal Murray]

> 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 
an Acutime?


> 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 192.94.41.130    3 u   35   64  377   34.511    1.586  0.602
-caffeine.cc.com 203.209.212.98   3 u   30   64  377   64.355   -7.665  4.964
-pond.thecave.ws 18.26.4.105      2 u   27   64  377   85.675   -2.443  0.314
xns.creativecont 121.0.0.41       3 u   39   64  377   51.255  -23.593 13.578
-tur-dmz2.massey 131.203.16.10    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.