[ntp:questions] The libntp resumee...

Kay Hayen 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.

Best regards,
Kay Hayen

More information about the questions mailing list