Date: Mon, 02 Aug 2004 13:52:32 -0600 From: "Jeff W. Boote" <boote@internet2.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: <410E9B80.F66B79C5@internet2.edu> References: <20040801043804.800F95D08@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?410E9B80.F66B79C5>