Looking for ntp/PPS setup guide

[Eric Brown]

On Sat, Jul 31, 2004 at 09:38:04PM -0700, Kevin Oberman wrote:
> > Date: Sat, 31 Jul 2004 21:25:04 -0400 (EDT)
> > From: Garrett Wollman <wollman at khavrinen.lcs.mit.edu>
> > 
> > In article <20040731231908.18F485D08 at ptavv.es.net> you write:
> > 
> > >From what I have seen, the non-kernel PPS software handles jitter more
> > >gracefully than the kernel version.
> > 
> > Which CDMA receiver do you have?  I'm using one from EndRun
> > Technologies which emulates a Trimble Palisade and it seems to perform
> > fairly well:
> > 
> >      remote           refid      st t when poll reach   delay   offset  jitter
> > ==============================================================================
> > *GPS_PALISADE(0) .CDMA.           0 l    1   32  377    0.000   -0.016   0.008
> > +NAVOBS1.MIT.EDU .PSC.            1 u   37   64  377    0.836    0.027   0.025
> > xtime-b.nist.gov .ACTS.           1 u   49   64  377   15.477   -6.898   9.374
> > +ntp2.usno.navy. .USNO.           1 u   10   64  337   40.016   -2.378  83.946
> > -gps.freebsd.dk  .GPS.            1 u   51   64  377  115.848    4.315   1.408
> > 
> > This receiver was recommended to me by Dave Andersen (dga@).
> > (Actually, I stole it from him.)  This is using the host-triggered
> > timestamp mode of this device rather than PPS.
> 
> I am running the EndRun Proesis Ct. It can emulate many different clocks
> and, if you don't have PPS, the Palisade is probably the best
> choice. Unlike others which send out the time in ASCII every second, the
> Palisade sends out the time in binary when polled. But this is not as
> accurate as PPS which the unit also provides.
> 
> The problem is that polling mode and PPS don't work properly together,
> so I have found that the TrueTime format provides the best results.
> ctime=off
> emul=truetime
> ctime=on
> 
> I am still looking at the best choice for PPS setup...PPS_SYNC (flag3 1"
> or software PPL "flag3 1". Both do very well. I suspect that the absolute
> time is closest with PPS_SYNC but the stability is often better with PLL
> discipline. If PLL proves the more stable, I will use a fudge of time1
> to correct for the offset. (In my last message bnl-owamp was running
> PPS_SYNC and the system I queries was running PLL. Note the 51
> microsecond offset. I don't know yet if that's real or an artifact of
> network delays.
> -- 
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: oberman at es.net			Phone: +1 510 486-8634

You reminded me of the other item I wanted to try to figure out.

Up until now I have been using PPS as my reference time.  I also
use a IRIG input so that the stratum of PPS will be 1.  I use a
time offset on the IRIG based on PPS.

It would be nice to find the true offset of the PPS signal given any
interrupt latency through kernel code.  I attempted to interface the
PPS output on the parallel port back to my DATUM receiver.  The receiver
will gladly measure the event time for me.  I couldn't make it work.

I was unable to verify if in fact the PPS output signal was configured.
If it was, then the remaining possibility is that I need some sort of
buffer between PPS output and event input on the receiver.

Any clues?

--Eric Brown