Date: Mon, 02 Aug 2004 15:23:32 -0700 From: "Kevin Oberman" <oberman@es.net> To: "Jeff W. Boote" <boote@internet2.edu> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: Looking for ntp/PPS setup guide Message-ID: <20040802222332.187025D09@ptavv.es.net> In-Reply-To: Your message of "Mon, 02 Aug 2004 13:52:32 MDT." <410E9B80.F66B79C5@internet2.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Mon, 02 Aug 2004 13:52:32 -0600 > From: "Jeff W. Boote" <boote@internet2.edu> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040802222332.187025D09>