Date: Sun, 1 Aug 2004 17:02:54 -0400 From: Eric Brown <brownej@locust.cns.vt.edu> To: Kevin Oberman <oberman@es.net> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: Looking for ntp/PPS setup guide Message-ID: <20040801210254.GA11061@locust.cns.vt.edu> In-Reply-To: <20040801043804.800F95D08@ptavv.es.net> References: <200408010125.i711P44H056311@khavrinen.lcs.mit.edu> <20040801043804.800F95D08@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@khavrinen.lcs.mit.edu> > > > > In article <20040731231908.18F485D08@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040801210254.GA11061>