[LinuxPPS] Occasionally ntpd stops receiving NMEA data

Udo van den Heuvel udovdh at xs4all.nl
Mon Jun 5 15:30:31 CEST 2006


Rodolfo Giometti wrote:
> On Mon, Jun 05, 2006 at 01:19:55PM +0200, Udo van den Heuvel wrote:
>> LINUXPSS_API is the variable to be checked by ntp.
>> (i.e.: do we have LinuxPPS? to include the header files)
> 
> I don't think NTP should check against LINUXPSS_API. It should check
> against PPS_API_VERS_1 or PPS_API_VERS_2 instead.

At that point (do we have LinuxPPS) we do not care about version 1 or 2
yet. We include the right header to get more info.
Later, at the relevant points, ntp can discern between version 1 and 2
when needed. (depending on ntp code and version dependencies)

> LinuxPPS is just an implementation of PPS API, so we should declare
> the PPS API supported with a define like PPS_API_VERS_x and the
> particular PPS implementation with the define LINUXPSS_API.

PSS?
If we are just one implementation, why does it check for PPS_API_VERS_1
and why did you change to PPS_API_VERS_2 when nothign serious changed so
far?
I get lost here.

If all linux PPS implementations have the same header file wen do not
need PPS_API_VERS_x for the first check.
Later the code can find out what PPS implementation is used by checking
PPS_API_VERS_x and similar defines.

>> Just PPS_API_VERS which can be either 1 or 2 for now should be enough.
>>
>> Just send in a patch to the ntp folks and *maybe* the next release will
>> behave differently.
> 
> This is a possibility but I don't think NTP folks will accept

Why not? The check was just there for LinuxPPS?
And if they see it is different for linux 2.6 we can hive them that
argument.

> something like this... they also refused modifying PPS API in order to
> consider non serial connected GPS antennas...

Poor them.

>> Can we skip stuff like this and concentrate on the issues I posted about
>> earlier?
>> Like simplifying and minimizing the changes to the ntp code?
> 
> This stuff are important in my opinion, since future patches will
> depend on these defines.

So it appears we have to adhere to the ntp `standard`.
No PPS_API_VERS change. We check in the LinuxPPS code for the right
version (for kernel 2.4 or 2.6 for example)


>> Maybe put a function layer in between so there's no changes needed?
>> (for the not LinuxPPS-aware applications)
> 
> About this topic I think we should open a new thread. However just to
> init the discussion, here my proposal:

Does it make the patch to ntpd smaller?

[...]

> In this manner we can surely address the right PPS device.

That is one problem that is also important.
I mean a solution to minimize the changes to ntp code while still using
your LinuxPPS implementation underneath.
Maybe even eliminate the need for changes?


Udo



More information about the LinuxPPS mailing list