From owner-freebsd-stable@FreeBSD.ORG Mon Aug 2 19:52:01 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 97E2C16A4CE for ; Mon, 2 Aug 2004 19:52:01 +0000 (GMT) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56A3743D3F for ; Mon, 2 Aug 2004 19:52:01 +0000 (GMT) (envelope-from boote@internet2.edu) Received: from localhost (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id ACF231CD5D6; Mon, 2 Aug 2004 15:51:58 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11679-07; Mon, 2 Aug 2004 15:51:58 -0400 (EDT) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 1769B1CD5DA; Mon, 2 Aug 2004 15:51:58 -0400 (EDT) Message-ID: <410E9B80.F66B79C5@internet2.edu> Date: Mon, 02 Aug 2004 13:52:32 -0600 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Oberman References: <20040801043804.800F95D08@ptavv.es.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by mail.internet2.edu virus scanner 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 19:52:01 -0000 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? > 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. (Another thing of note if you are using this EndRun device: Make sure you set "flag2 1" for the PPS device. It is the "clear" of the PPS signal that is synchronized.) jeff