From owner-freebsd-stable@FreeBSD.ORG Mon Aug 2 22:23:33 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 7B3BC16A4CE for ; Mon, 2 Aug 2004 22:23:33 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6517143D66 for ; Mon, 2 Aug 2004 22:23:33 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Mon, 02 Aug 2004 15:23:32 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 187025D09; Mon, 2 Aug 2004 15:23:32 -0700 (PDT) To: "Jeff W. Boote" In-reply-to: Your message of "Mon, 02 Aug 2004 13:52:32 MDT." <410E9B80.F66B79C5@internet2.edu> Date: Mon, 02 Aug 2004 15:23:32 -0700 From: "Kevin Oberman" Message-Id: <20040802222332.187025D09@ptavv.es.net> 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 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2004 22:23:33 -0000 > Date: Mon, 02 Aug 2004 13:52:32 -0600 > From: "Jeff W. Boote" > > Kevin Oberman wrote: > > 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 > > Specifically, If I remember correctly... the binary format used by the > palisades driver uses the same pin as PPS making them incompatible > (DCD?). > > > 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 > > PPL would be "flag3 0", right? Yes, PLL (I typed PPL about 5 or 6 times) would be "flag3 0". I am a truly terrible typist and spell check does not catch these things. > > 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. > > That is an interesting idea. I have not tried that yet. I may try "flag3 > 0" on one or two of our systems and see if the stability improves. (We > have 11 of these in service at the moment... The places we have real > stability problems now is where we tend to loose CDMA service for > portions of a day.) > > One thing we have noticed is that the TrueTime output seems to have a > fairly large offset relative to the PPS output of the device. (i.e. The > two outputs of the exact same device seem to have a non-trivial offset > from each other.) This causes a fair bit of instability. To compensate > for this, we have been using a fudge of time1 to correct the TrueTime > output. (11 msec's is what we have found works but I suspect this is PC > hardware and OS dependent.) I am not sure how much of this delay is due > to the polling nature of the TrueTime NTP driver verses the more event > driven PPS implementation in the kernel. To determine the 11 msec value, > we used the enable calibrate mode of NTP and waited for the offset to > stabilize for a couple of days. I've been using 10 ms. on mine, but 11 may be better. Time will tell which approach is better. Based on testing over the weekend, I suspect that I will be switching back to PPS, but I'll let things run a bit longer before making a final decision. -- 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