Hello, 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 parser. But I have to thank you people for extra points made and things I have learned: 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 responsability. 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 _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
