[LinuxPPS] 2.6.22.1 x86_64 + ntp-4.2.4p3 + gpsclock

Frank Kardel kardel at ntp.org
Tue Aug 7 08:13:27 CEST 2007


Hi Udo !

> Rodolfo Giometti wrote:
>> On Sun, Aug 05, 2007 at 09:06:29PM +0200, Udo van den Heuvel wrote:
>>> Pending the answer to this question, here is my latest atom patch.
>>> I did not yet test it but it compiles OK and was made following the
>>> ways
>>> of the NMEA patch.
>>> Please give the patch a review.
>>
>> It seems ok to me. :)
>
> Just tested; pps does not work. ntpq -pn does not show pps as a source
> and messages say:
>
> Aug  7 07:06:19 epia ntpd[27304]: refclock_nmea: found PPS source
> "/dev/ttyS0" at id #0 on "serial0"
> Aug  7 07:06:19 epia ntpd[27304]: refclock_nmea: time_pps_kcbind failed:
> Operation not supported

This operation refers to the kernel pll discipline. LinuxPPS does
not support that, so this call is bound to fail unless something
comparable to the nanokernel implementation of Dave Mills is
available in the Linux kernel an integrated with LinuxPPS.
PPSkit did such a thing, but the changes for that are not trivial.

Ideally refclocks should excercise time_pps_kcbind only if configured
to do so. Also, they should give up if it doesn't work. So, maybe
some fixes in refclock_nmea.c may be required wrt/ time_pps_kcbind().

> Aug  7 07:06:19 epia ntpd[27304]: refclock_atom: found PPS source
> "/dev/ttyS0" at id #0 on "serial0"
> Aug  7 07:06:19 epia ntpd[27304]: configuration of 127.127.22.0 failed
>
ATOM configured ok as it wasn't configured (flag3 IIRR) to do a
time_pps_kcbind().

> So more tweaking?
>
Maybe make refclock_nemea.c survive a failing time_pps_kcbind.

Regards,
  Frank




More information about the LinuxPPS mailing list