[ntp:questions] No libntp.so

Unruh unruh-spam at physics.ubc.ca
Fri Aug 29 14:44:25 UTC 2008


Martin Burnicki <martin.burnicki at meinberg.de> writes:

>Bill,

>Unruh wrote:
>> martin.burnicki at meinberg.de (Martin Burnicki) writes:
>> 
>>>Hello Kay,
>> 
>>>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 silly.

>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
>done independently.

>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. There is
not 25ms urgency. 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. 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.






More information about the questions mailing list