[ntp:hackers] About time_pps_kcbind()
hundoj at comcast.net
Thu Oct 9 20:20:03 UTC 2008
On Mon, 6 Oct 2008, Venu Gopal wrote:
> Hi Friends,
> I have been working with the LinuxPPS for Linux 2.6 series kernel
> since a week.
> There are patches for few refclock drivers to make them work with LinuxPPS
> implementation, which otherwise use PPS Kit written by Ulrich Windl with
> Linux 2.4 kernels.
> One such patch was submitted my Udo for NMEA refclock driver. So we are
> towards adding this patch to NTP mainstream(BUG#610). Now this new PPS
> doesn't implement the optional *time_pps_kcbind*() function. This is
> used by the refclock drivers
> where in a flag by name *pps_enable* is set true if the function call
> succeeds. This flag is
> in turn used in *ntp_loopfilter.c*. I am not aware of the significance
> this flag plays when
> enabled or otherwise.
> I have an experimental setup with three boxes running
> 1. FreeBSD-6.2 (recompiled with PPS enabled),
> 2. Linux-2.4.20-NANO and
> 3. Linux-2.6.23 (patched with LinuxPPS) respectively.
> As per my observations, when the pps_enable flag is not set (when using
> LinuxPPS), the offset
> keeps increasing and never comes down. So I set the pps_enable flag to
> true (even though the
> function fails), then I see the offset slowly coming down from few
> milliseconds to sub-microseconds
> and settles fine.
> Only today morning I started running NTPD with pps_enable set to false
> to see if the results repeat.
> as observed initially and so far the results are not encouraging.
> I need comments on the importance of pps_enable flag from the
> experienced guys.
> hackers mailing list
> hackers at lists.ntp.org
I don't think I'd call myself expert, but I believe the pps_enable flag to
control the kernel participation.
As an aside, time_pps_kcbind() may be optional, but it isn't
terribly difficult to implement. You do yourself a disservice by
not suporting it, IMO.
More information about the hackers