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: http://www.cubinlab.ee.unimelb.edu.au/radclock/articles.php 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: http://www.eecis.udel.edu/~mills/ntp/html/prefer.html And the so-called "Shared memoy Driver" [sic]: http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver28.html Also the PPSAPI driver (in case you're able to switch from Linux or have a very old kernel with the ppsapikit): http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions