[ntp:questions] No libntp.so
unruh-spam at physics.ubc.ca
Thu Aug 28 17:59:21 UTC 2008
kayhayen at gmx.de (Kay Hayen) writes:
>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
You send each host an ntp request packet and look at the times they report
back. Accurate to a few 10s of micro (not milli) seconds if they are all on
your local lan.
>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.
Set up a local gps timeserver, and use the external ones as fallback.
The stratum is determined by the distance from an authoritative source. It
is not reallysomething that you assign.
I think by "peer" you mean"serve".
But finding out that that an external source has failed is not something
that requires 25ms accuracy. Or even seconds accuracy. Maybe hours.
After all ntp does not query the external sources more than once every 20
min, and then throws away 80% of those queries anyway. Ie, there is no
>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
Sure. But the key issue with any time criticality is to make sure that the
computers all share a time base.
That you can do with ntp queries, not ntpq. Ie, the whole of ntp is set up
precisely to answer with high accuracy, the main question you want to ask.
And the structure of an ntp packet is open and well known and can be sent
out by whatever software you want. It does not have to be ntpd which sends
the query. The other machines just see the packet and respond with their
own timestamps. The latency is the latency of your network, and the cost is
a single packet each way. (about 16 bytes each way).
This of course assumes thatthose machines are running ntpd, and will
respond to queries, but since we are discussing ntpd it can.
More information about the questions