[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
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.
Best regards,
Kay Hayen
More information about the questions
mailing list