[ntp:questions] No libntp.so

Kay Hayen kayhayen at gmx.de
Wed Aug 27 23:52:48 UTC 2008

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, bare 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 

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.

Best regards,
Kay Hayen

More information about the questions mailing list