[ntp:questions] No libntp.so

Martin Burnicki martin.burnicki at meinberg.de
Wed Aug 27 10:57:23 UTC 2008


Kay,

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

Even if you would be made available als shared object file it would not
provide the full ntpq functionality.
 
> Our aims can be realized (and must be short term it seems) with a fork of
> your work that builds a shared library for use in our software. While that
> is workable, it is also bad thing to do in the first place.
> 
> What we really would prefer instead, is to see is the addition of a target
> to your makefile to make a libntp.so buildable. Then, we could already use
> the original releases as from you. From there we would work with
> downstreams (Debian and RHEL) to convince them to include libntp.so in the
> NTP packages and (libntp.a and headers obviously) possible through some
> ntp-devel package, at which point we could drop building from source
> again.

IMHO it would not make much sense to provide the existing libntp as shared
object library. There is some ongoing work which will encapsulate the ntpq
functionality in a shared object library, so it would be easier to use from
an own application. 

However, those calls may also block, so the basic requirement to call those
functions from an own tread/task would be unchanged. 
 
> The question of course would be: Will you merge such Makefile patches from
> us in the first place. And do you see any reason why this should not be
> done like this. After all, it has not been done for a long time already,
> so possibly this is on purpose?
> 
> 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.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list