[ntp:questions] Sole time source in Linux user space.

Bruce Lilly bruce.lilly at gmail.com
Sat Jul 3 12:54:10 UTC 2010

On Wed, 30 Jun 2010 13:50:44 +0000, Michael Eder wrote:

> [...]  The time source is
> composed of a date and time string accurate to seconds, and a highly
> accurate Pulse-Per-Second.  I expect the shared memory interface to NTP
> is the way to do this, but what is not clear to me is if I can enter the
> time as a single source or I should separate out the Pulse-Per-Second
> from the date and time string and configure them as separate sources.

It depends (that's the standard answer to all questions ntp-related).  It 
specifically depends on what accuracy and precision you hope to obtain, 
how you plan to physically interface your source PPS and string 
information to the device, whether you are stuck with a specific Linux 
kernel or are willing to recompile from source, which Linux kernel you 
have, whether you are indeed committed to Linux or could use e.g. FreeBSD 
instead, how much you are willing and able to tweak your system.
> The Pulse-Per-Second is highly reliable, but I can imagine a situation
> where the date and time string might not be available.  This is
> especially a concern if the system shuts down and restarts.

The way the reference ntp implementation handles this is to configure two 
separate sources, with the PPS source using a specific driver which uses 
a specific (viz. ppsapi) software interface to the hardware (which is 
typically either a serial port control signal (usu. DCD) or a parallel 
printer port signal.  Although you will find ntp documentation that 
asserts that there is a ppsapi interface for Linux, that was true of 
older kernel series with an optional patch; there is not yet a working 
mainstream implementation for Linux 2.6 series kernels.  What little that 
does exist for 2.6 (as of the last time I looked) consists of partial 
source code which is not in a source code file, but is instead in a 
Documentation tree file, and that doesn't do much good even if you move 
it to where it should be because the serial driver code hasn't yet been 
interfaced to it.

A caveat about interfacing via serial ports; unless you are willing to 
live with jitter and inaccuracy on the order of 1 million nanoseconds 
(a.k.a. 1 millisecond), don't even think about a serial-to-USB converter 
and a USB interface for the PPS signal. USB has no provision for control 
signals such as DCD; it is polled at 1000 Hz (which leads to the 1 
millisecond jitter and inaccuracy).  USB = Ugly (dozens of incompatible 
connectors) Sloppy (1 million nanoseconds worth of slop) Botch.

Another caveat is that the ntp algorithms assume gaussian distribution of 
errors, but typical serial port hardware/drivers result in a non-normal 
distribution (specifically with a very long one-sided tail resulting from 
interrupt processing delays), at least with general-purpose (as distinct 
from real-time) kernels.  The samples near the (short, almost 
triangualar) tail of the other side of the distribution correspond to 
rapid processing of PPS signals and are what really should be used; the 
long tail corresponding to delayed processing skews the sample mean, 
median and other statistical measures which are more suited to a Gaussian 
distribution.  USB (see above) is even worse; the polling essentially 
results in a flat (rectangular) distribution.  There appears to be an 
unrelated project that attempts to address the non-normal distribution 
for non-USB sources, but it requires building a custom kernel and the 
last time I looked there was no support for recent kernels:

Regarding accuracy and precision, most of the ntp reference 
implementation deals with time to nanosecond precision if the OS kernel 
supports it.  The SHM shared memoy [sic] driver is an exception; it 
handles microsecond precision only, and multiplies by 1000 to interface 
to the rest of the ntp code.  Specifically for current Linux kernels, 
there is a related issue in that the glibc header files used by Linux do 
not properly define macros that indicate nanosecond kernel support, so 
you'll have to do some tweaking there if you need to build ntp with 
nanosecond support on Linux.

The shared memoy [sic] driver also has a hard-coded interface to ntp 
which indicates the type of the source; moreover that varies with version 
(e.g. in the ntp reference implementation version 4.2.6 all shared memory 
sources are hard-coded to indicate that they are modem sources regardless 
of what the actual source is; in 4.2.6-p1 that was changed to indicate 
that all sources are UHF radio sources (such as GPS) regardless of what 
the actual source is).  In theory you could tweak the driver to handle 
your specific situation and rebuild ntp.

> [...]
> Is there any place where I can find documentation about how NTP handles
> different clocks and different information that clocks may provide? 
> Where do I find documentation of how to configure these shared memory
> time sources?
> Pointers much appreciated.

Much of what you're looking for can be found in the ntp reference 
implementation documentation, which is provided only in HTML format.
It is recommended to use the documentation for the specific version that 
you're using, but if that's not practical, you can find online versions 
such as:

A good starting point, with links to other topics:

And the so-called "Shared memoy Driver" [sic]:

Also the PPSAPI driver (in case you're able to switch from Linux or have 
a very old kernel with the ppsapikit):

More information about the questions mailing list