[LinuxPPS] My ATOM clock is working fine now, should I have sys.peer?

[Paul Simons]

Someone pointed out earlier that I was using the "clear" rather than the "assert" edge, and I blithely pointed them to the wiki and moved on.  Well, it bothered me enough that I tried using the assert edge, and it worked!  This does make sense; I must have read the time stamps wrong. 

# ntpq -c rv -c ass -p 

associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync, 

version="ntpd 4.2.5p158 at 1.1809-o 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=0.403, refid=PPS, 

reftime=cd3d6fe3.8c33c3df  Wed, Feb 11 2009  7:40:19.547, 

clock=cd3d6fed.7b66f14e  Wed, Feb 11 2009  7:40:29.482, peer=33855, 

tc=4, mintc=3, offset=-0.033, frequency=-89.630, sys_jitter=0.002, 

clk_jitter=0.002, clk_wander=0.001 

ind assid status  conf reach auth condition  last_event cnt 

=========================================================== 

  1 33855  974a   yes   yes  none  pps.peer    sys_peer  4 

  2 33856  941b   yes   yes  none candidate clock_alarm  1 

  3 33857  9424   yes   yes  none candidate   reachable  2 

  4 33858  9324   yes   yes  none   outlyer   reachable  2 

  5 33859  9324   yes   yes  none   outlyer   reachable  2 

  6 33860  9324   yes   yes  none   outlyer   reachable  2 

  7 33861  9324   yes   yes  none   outlyer   reachable  2 

     remote           refid      st t when poll reach   delay   offset  jitter 

============================================================================== 

oPPS(1)          .PPS.            0 l   10   16  377    0.000   -0.033   0.002 

+TRUETIME(0)     .TRUE.           0 l   24   64  377    0.000   -6.401   0.016 

+clepsydra.dec.c .GPS.            1 u   23   64  377   55.437    7.373   0.710 

-clock.xmission. .GPS.            1 u   54   64  377   73.582    7.880   0.505 

-bigben.cac.wash .USNO.           1 u   29   64  377   39.912    7.609   0.619 

-131.107.13.100  .ACTS.           1 u   27   64  377   54.317   16.825   1.296 

-clock.sjc.he.ne .CDMA.           1 u   16   64  377   53.063    8.050   0.401
This has been running for about twelve hours.  Should the TRUETIME condition become sys.peer at some point?  Or does this look good?

ntpq> clockv 33856
associd=33856 status=00f0 , 15 events, clk_unspec,
device="Kinemetrics/TrueTime Receiver", timecode="042:16:08:15 ",
poll=987, noreply=0, badformat=0, baddata=0, fudgetime1=0.000,
stratum=0, refid=TRUE, flags=0

Is there a way to zero the status?  I don't know when those "clk_unspec" events occurred.  Are they keeping the clock from becoming sys.peer?

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20090211/5e5b4b42/attachment.htm