[LinuxPPS] Why is my ATOM clock a falseticker?

[James Boddington]

Paul Simons wrote:
> 
> I moved to p158 and the times are correctly translated again: 
> 
> # ntpq -c rv -c ass -p
> associd=0 status=00b8 leap_none, sync_unspec, 11 events, no_sys_peer,
> version="ntpd 4.2.5p158 at 1.1809-o[1] Mon Feb  9 04:32:17 UTC 2009 (1)",
> processor="i686", system="Linux/2.6.26.simonet", leap=00, stratum=1,
> precision=-19, rootdelay=0.000, rootdisp=2.071, refid=TRUE,
> reftime=cd3a392b.fff1aea4  Sun, Feb  8 2009 21:10:03.999,
> clock=cd3a3956.aa9bebb6  Sun, Feb  8 2009 21:10:46.666, peer=0, tc=6,
> mintc=3, offset=0.448, frequency=-88.714, sys_jitter=0.051,
> clk_jitter=0.050, clk_wander=0.003 
> 
> ind assid status  conf reach auth condition  last_event cnt
> ===========================================================
>   1 36392  914a   yes   yes  none falsetick    sys_peer  4
>   2 36393  913b   yes   yes  none falsetick clock_alarm  3
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> xPPS(1)          .PPS.            0 l   28   16   76    0.000  -493.19   0.002
> xTRUETIME(0)     .TRUE.           0 l   43   64  377    0.000    0.448   0.051
> 
> Could the problem be with the "reach"? It seems that ntpd can always reach the TRUETIME, but frequently does not reach the PPS. 
> 
> 1. I did find time fudge in the TRUETIME driver, but I wanted to bring up the above question first. 
> 
> 2. The Wiki indicates that the ATOM driver does not need to be patched (That is the main reason I picked it instead of modifying the TRUETIME driver).  Does anybody else use the ATOM driver?  Or is it better to modify the specific clock driver? 
> 

I use the atom driver, isp's ntp server as the prefer peer and a few pool 
servers for sanity checking. Did not have to modify the atom driver.

It looks like you only have 2 clocks defined. That is not a good number.

Ntp syncs to the TRUETIME and once that happens starts listening to PPS. The 
reach for PPS won't increase until ntp is synced to the TRUETIME. When both are 
going you have approx 493ms difference between the 2 sources. Which is ntp to 
believe? It won't know and you end up with both being declared false tickers. 
If you had a 3rd server defined then ntp would start getting an idea of which 
was correct.

Can you add other servers for sanity checking?

Try fudge time1 for the TRUETIME to reduce the gap. If the 2 times are close 
enough you might get lucky. If you are using nmea with it the time could still 
jump enough you are back you to this point. From reading 
comp.protocols.time.ntp I get the impression one of the tinker variables can be 
used to increase the max difference between the prefer peer and the pps before 
something is declared insane.

-- 
    James