[ntp:questions] No libntp.so
mayer at ntp.isc.org
Wed Oct 1 03:14:42 UTC 2008
Martin Burnicki wrote:
> Kay Hayen wrote:
>> Hello NTP-World :-),
>> we are implementing a NTP supervision for our ATC middleware. Initially we
>> are doing it by repeated "ntpq" executions and textual evaluations of the
>> results. We have had to notice that pipes are very unsuited for the task,
>> so we really fork it and close its stdin to make it flush. It works, but
>> it is unconvincing in performance (latency).
>> 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 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.
> A proper approch would be to start a thread or task which would do the ntpq
> stuff asynchrounously and report the results to your main application when
> the reply has become available.
Well any application that depends on using ntpq or any of its
functionality is broken by definition unless it's used for monitoring
>> As we would like do other important stuff in the same process, we would
>> like to do that faster. So I had a look at the source and found that ntpq
>> is using a libntp.a that nobody seems to package though. There is no
>> libntp.so either, we had searched for those initially, but no luck.
Libntp is not intended for such usage. It's intended just to provide
common functions across a number of applications in the ntp suite.
> Libntp just contains a couple of functions which are shared between several
> programs of the NTP package, e.g. ntpd, ntpq and others. It is used during
> the build process of the package in order to save compiule time.
That's probably not an issue any more. It was when we had to build on
Ultrix on the flock but most modern hardware it's not really an issue.
>> Obviously we hope you will allow us to be good Free Software citizens and
>> let us drop the fork down the road. Will you?
> The question is not basically whether a patch is accepted. In the first
> place the question is whether a patch makes sense at all. As already
> mentioned above I think it does not much sense just to provide libntp
> as .so file.
Whether or not we build a libntp.so or libntp.a is not as important as
it is to move more of the common functionality into the libntp library.
More information about the questions