[ntp:questions] No libntp.so

Martin Burnicki martin.burnicki at meinberg.de
Fri Aug 29 07:46:06 UTC 2008


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.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list