[ntp:questions] NTP & PPS, part 2 ;)

Martin Burnicki martin.burnicki at meinberg.de
Tue Dec 16 13:46:07 UTC 2014

Harlan Stenn wrote:
> Martin,
> Martin Burnicki writes:
>> Harlan Stenn wrote:
>>> Martin Burnicki writes:
>>>> IMO the best approach would be to detect this at runtime.
>>> That means we'd need a header file...
>> It shouldn't be a problem to add this to the NTP code base.
>>> If I'm not mistaken (and it's getting late for me), if the header file
>>> is missing we don't expect the API.  If the header file is present we
>>> expect it to "do the right thing" and even then we check error returns
>>> from the API.
>> What I meant is to build ntpd with the header file present, and then
>> check at runtime (ntpd startup) if the API is really present.
> Please look at the differences between timepps-{SCO,Solaris,SunOS}.h and
> also whatever you are using on the OSes you have easy access to (*ix and
> Windows) and let me know if you still think us providing this file is a
> reasonable thing.  For extra points, see how the timepps.h equivalent on
> each of these OSes has changed over the years, and how "life will be
> better" if appropriate versions of that file live in *our* codebase
> instead of finding them on the OS we're building for.  We can, of
> course, expect updates to these files from a variety of sources in the
> future.

I'm not familiar with the PPS API provided by {SCO,Solaris,SunOS}. The 
header files have to match the implemented API, and at least the API 
supported by current Linux systems should be conforming to the RFC which 
exists today and implements the API.

So similarly as ntpd (at least the -dev version for now) tests at 
runtime whether another daemon feeding the SHM segment supports 
nanoseconds, it should be able to try to find out if a PPS interface 
according to the RFC is provided.

> It might very well be that we can separate some of these "parts" into an
> "internal" and an "external" file, but again, we've been down this path
> before with the MOD_NANO and STA_NANO stuff; why would we want to
> *invite* this kind of difficulty in the future?

With nanoseconds support it's similar. The configure script just tries 
to find out if the kernel supports it by testing some define at compile 

If I remember correctly then in earlier Linux versions the directory 
/usr/include/linux/ pointed to the real Linux headers, including the 
kernel config file, which had presumably been used to build the 
currently running kernel.

Maybe at that time it was possible to check if a patch with nanoseconds 
support for the kernel had been applied. In later Linux distros 
/usr/include/linux/ didn't point to the real, configured kernel sources 
but to a set of include files from a recent kernel version which were 
provided by the compiler and associated runtime library.

This may have been sufficient for some applications which needed to know 
some generic structures supported by the kernel, but it could easily 
fail if you tried to determine from the generic kernel header files if 
the currently running kernel was built with or without nanosecond 

I know at least one Linux distro which was shipped at that time with an 
ntpd built under wrong assumptions. As a consequence, the time 
adjustments ntpd passed to the kernel were computed wrong, and the 
offset reported by "ntpq -p" always toggled by about 1 millisecond 
instead of microseconds.

This is another example where testing nanoseconds support at runtime 
would have worked better.

Fortunately, AFAIK all current Linux kernels are compiled with 
nanosecond support, so this problem doesn't seem to occur anymore on 
current Linux systems.


More information about the questions mailing list