[ntp:questions] The libntp resumee...
kayhayen at gmx.de
Fri Sep 5 06:55:26 UTC 2008
thanks to all who replied. Unfortunately the moderation bit made all of my
last replies expire and instead of reposting them, I choose to sum things up
in a single post.
The original question was answered. What I really wanted was a libntpq anyway,
and Heiko has already contributed a libntpq.a as well as a NTP SNMP daemon,
both of which we want. I understand it's part of ntp-dev, but didn't have the
chance to look on it (I was on a site visit this week). The plan certainly is
to use that work and I am heavily reliefed that one apparently no longer has
to fork the ntpq code base privately just to avoid the external process and
But I have to thank you people for extra points made and things I have
1. Mentioning the "25ms" as too long was a very bad idea from me, it sure
provided only for distraction. I wasn't interested at all in discussing if
that's a time frame that matters or not. In my world, every delay to
accessing information needs another justification than "not needed as fast",
but that leads to distraction as everybody may or may not subscribe to that
point of view.
2. I understood that it will be way better to monitor the offset of "external"
NTP servers via the small time query packets that ntpd use among themselves.
We will be able to determine a offset and restrict NTP servers that appear to
malfunction. Benefit: We potentially could disable it in some cases, before
it ever has an impact on our ntpd servers.
3. I was not clear enough that our NTP interest has two roles. One as the
maker of a specific system with specific NTP setup in place for which we have
provided support. In that role I have come to learn about the necessity of
NTP monitoring. Two as the maker of a middleware, where we can't tell people
to change their environment, but are to monitor it. Avoiding errors is
interesting in the first setup, in the second it's not our option and
4. Also I learned about the orphaned mode. It wasn't available when our
current setup was designed (more than 7 years ago I think) and will make for
a nice enhancement proposal for our system.
5. The NTP rules about how often to query a daemon. I have tried to read up
about it, but only found general advice. Under the assumption that ntpd is
not multithreaded querying it at the time it should respond to other servers
is slightly unfortunate. I was thinking that the query is so fast that it
doesn't matter. I will have to back it up with numbers. I presume we could
query the local ntpd for its time in a loop and compare with local current
time to get an idea if extra libntpq queries degrade it or not.
More information about the questions