From owner-freebsd-stable@FreeBSD.ORG Sun Aug 1 21:02:56 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C82116A4D1 for ; Sun, 1 Aug 2004 21:02:56 +0000 (GMT) Received: from locust.cns.vt.edu (locust.cns.vt.edu [198.82.169.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6BC643D5D for ; Sun, 1 Aug 2004 21:02:55 +0000 (GMT) (envelope-from brownej@cns.vt.edu) Received: by locust.cns.vt.edu (Postfix, from userid 10701) id 0B8A614A4C; Sun, 1 Aug 2004 17:02:55 -0400 (EDT) Date: Sun, 1 Aug 2004 17:02:54 -0400 From: Eric Brown To: Kevin Oberman Message-ID: <20040801210254.GA11061@locust.cns.vt.edu> Mail-Followup-To: Eric Brown , Kevin Oberman , Garrett Wollman , FreeBSD-stable@FreeBSD.org References: <200408010125.i711P44H056311@khavrinen.lcs.mit.edu> <20040801043804.800F95D08@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040801043804.800F95D08@ptavv.es.net> User-Agent: Mutt/1.4.2.1i cc: FreeBSD-stable@FreeBSD.org cc: Garrett Wollman Subject: Re: Looking for ntp/PPS setup guide X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: eric.brown@vt.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2004 21:02:56 -0000 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 > > > > 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