[ntp:questions] No libntp.so

Joseph Gwinn joegwinn at comcast.net
Thu Aug 28 13:39:04 UTC 2008

In article <200808280152.48311.kayhayen at gmx.de>,
 kayhayen at gmx.de (Kay Hayen) wrote:

> Hello Joseph,
> Am Mittwoch, 27. August 2008 15:00:25 schrieb Joseph Gwinn:
> > In article <200808260659.13498.kayhayen at gmx.de>,
> >
> >  kayhayen at gmx.de (Kay Hayen) wrote:
> > > Hello NTP-World :-),
> > >
> > > we are implementing a NTP supervision for our ATC middleware. Initially
> > > we are doing it by repeated "ntpq" executions and textual evaluations of
> > > the results. We have had to notice that pipes are very unsuited for the
> > > task, so we really fork it and close its stdin to make it flush. It
> > > works, but it is unconvincing in performance (latency).
> >
> > What exactly is "NTP supervision"?  What problem does it solve?
> I will gladly give examples of NTP functioning perfect and it still being 
> needed, bear with me if they lack in one way or the other:
> a) Suppose you have a system of 10 hosts that must have near identical time, 
> even if not correct. You may be using PC hardware with non-optimal clocks 
> because DEC is no more. You want to know if one node has an offset higher 
> than say 200ms. Can happen, and then you want to know, you don't even want to 
> start the software if e.g. right after boot these conditions are not already 
> met.
> b) Suppose you have 2 hosts of these 10, and they are the only ones with 
> connection to an "NTP LAN". They peer the 5 or even 7 external NTP servers 
> that you have. For the case that the "external" NTP servers with low stratum 
> values failing, you make those 2 external hosts peer another, but at high 
> stratum value. But if that has happenen, you want to know, because isolation 
> from external time input will lead to trouble sooner or later.
> c) Suppose you have bought that fine NTP clock from a fine vendor, but it 
> doesn't always work reliable. Some of them behave strange. I have seen my 
> share of them. I think I know of a clock that doesn't work correctly when 
> there is too much traffic on the LAN, it seems to be able to decode only so 
> much in a given time, then drop things. The NTP algorithms correctly flag 
> that clock (I don't know as what exactly they did, I didn't analyse that 
> myself), but it's certainly nice to see that reported on your SNMP system 
> where something becomes red instead of some log file only or false results 
> from the software.
> I think "NTP supervision" mainly has to solve the problem of not allowing the 
> software to continue on system with currently bad clock input and interfacing 
> in a nice way with SNMP based supervision systems where a technical watch 
> operator can easily visualize the health status of a system and take 
> necessary actions.

OK.  I see the problem.

One simple and very fast approach that occurs to me is to write a small 
C program that sends a NTP packet to each of the NTP servers in 
question, and compares the resulting reply packets.  By NTP rules, a 
given server should be queried no more than once per minute, and even 
that is probably faster than your application requires.  Sounds like 
once per startup is more like it.

NTP packets are small and simple, and the NTPv3 packet format is 
documented in Appendix A of RFC-1305.  I would use the NTPv3 packet 
format for compatibility with both NTPv3 and NTPv4 servers.  

Joe Gwinn

More information about the questions mailing list