[ntp:questions] Sole time source in Linux user space.
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
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