On 10/13/2011 17:38, Dave Hart wrote:
On Thu, Oct 13, 2011 at 22:57, A C<[email protected]> wrote:
I already had a GPS setup as PPS(1) and system offset was
mostly zero +/- a few microseconds.
Right, I get the same thing if I don't set time1 at all. When I do set
time1 I get the value of time1 plus or minus some microseconds as an offset
that is always displayed in the peer list. It never settles out to zero
like all the other clock drivers do even when they have a time offset set on
the fudge line.
I am pretty sure you can fix this by disabling kernel PPS sync, that
is, by not using flag3 1.
PPSAPI provides a way to pass a fudge (offset) to be applied to PPS
timestamps, but the common PPSAPI code in ntpd used by the PPS and
NMEA drivers (among others) does not use it. As a result, when you
enable so-called hardpps, where the kernel disciplines its clock
directly to the PPS, the time1 fudge is not used by the kernel
hardpps.
Once you verify things behave as expected without flag3 1, please file
a bug report at http://bugs.ntp.org/ noting the incompatibility of
flag3 1 and time1.
This test without flag3 will have to wait a little bit. I'm still
trying to debug a system lockup that may be related to ntpd when it is
being polled for peer status by ntpq from a remote host. I'll probably
be posting about that in a few days though the short summary is that
polling ntpd once every five seconds from a remote machine (using ntpq)
caused the ntpd system to completely freeze after about 20 hours. I
stopped the ntpq polling and so far the machine has been up for a week
without a problem.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
