[ntp:questions] No libntp.so
martin.burnicki at meinberg.de
Mon Sep 1 09:07:15 UTC 2008
> Martin Burnicki <martin.burnicki at meinberg.de> writes:
>>> martin.burnicki at meinberg.de (Martin Burnicki) writes:
>>>>Kay Hayen wrote:
>>>>> Hello Martin,
>>>>> thanks for the reply, you wrote:
>>>>>>As mentioned in another reply it depends on what ntpq has to do during
>>>>>>those 25 milliseconds. Please be aware that this may include DNS
>>>>>>lookups which might fail, so the the call would be take until the DNS
>>>>>>lookup times out.
>>>>> We are using "ntpq -n" which makes a huge difference for the peers
>>>>> command and make all DNS lookups obsolete. We are also not using DNS
>>>>> on these machines, but only a hosts file, so normally this couldn't
>>>>> play a role.
>>>>OK. However, if 25 milliseconds is still too long for other task you are
>>>>running you should do this asynchronously anyway.
>>> My suspicion is that are using those ntpq queries to try to figure out
>>> if the remote machines are "on time". Ie they use ntpq to query the time
>>> on the remote machine, and then read the time on their local machine to
>>> see if the remote machine is out of time sync. Then 25ms would be a long
>>> time. However, using ntpq to determine the time on the other machine is
>>In his first message Kay wrote:
>>> It appears that the whole ntpq call is relatively slow when, when we do
>>> it on e.g. RHEL 5.1 on modern Dual Core hardware, we get up to 25ms
>>> execution time, which is very long for us.
>>> As we would like do other important stuff in the same process, we would
>>> like to do that faster. [...]
>>If I understand this correctly then he's just doing the ntpq query and
>>some other processing in one loop. If the ntpq call takes 25 milliseconds
>>to execute then the other processing is delayed by that amount of time.
>>That's why I think the approach to run those ntpq queries in an extra
>>thread/process would be better. BTW, this would also be a better approach
>>if his application would just send time (client) requests to a server and
>>wait for the response before continuing to do other processing.
>>If this is done in an extra thread then both the query rate and the
>>execution time have no effect on some other processing which needs to be
>>If his applications does not just want to check the current time offset of
>>a remote node but collect some more information then using the ntpq
>>functionality is a good way to go. If the basic functionality would be in
>>a shared object library then it would just be easier to use, e.g. those
>>functions could just return a string buffer which could be parsed instead
>>of letting ntpq print to stdout and then pipe this into your own
>>application, which may introduce problems with line buffering.
> ntpq will not give the current time offset. It will give the offset last
> time packets were sent out and filtered which could be hours ago.
I'm aware of this. In the text you quoted from my last post above I wrote:
"If his applications does **not** just want to check the current time offset
of a remote node but collect some more information ..."
> There is
> not 25ms urgency.
Not from the point of view for ntpq, but for other tasks that the OP was
going to run in the same program loop as the blocking ntpq query. I've
already pointed out above that this is no good programming technique.
> But then he has not responded as to what he needs from
> ntpq and why he needs a less than 25ms latency on that query, so anything
> we do is guessing.
Basically it's his own decision which information he wants to collect from
ntpd using ntpq functionality. As I've already mentioned earlier our NTP
time server monitor program for Windows contains similar functionality.
When I came in touch with NTP I first learned that you have to look at the
output of "ntpq -p" if there's a '*' at the beginning of one line the NTP
daemon uses that time source as system peer and claims to be synchronized.
Some time later I learned that ntpd may not even claim to be synchronized if
the '*' is available, instead you have to look for "state=4" in the output
of "ntpq -c rv". Now in the current ntp-dev version the state variable has
been removed so you have to find another way to check whether ntpd is
synchronized or not.
> Modulo that your suggestion is undoubtedly better than
> what he is doing. But he seems fixated on NTP people fixing their software
> for his solution rather than finding the best solution for his problem.
I think this is just a little bit of misunderstanding because he's not yet
too familiar with the way NTP works. We can just point him in the right
More information about the questions