[ntp:questions] No libntp.so
unruh-spam at physics.ubc.ca
Tue Aug 26 19:31:00 UTC 2008
kayhayen at gmx.de (Kay Hayen) writes:
>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).
Why not fflush it? And why would you need lack of latency. It is a report.
It is not time critical or should not be. What you are doing sounds bizzare
>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.
What in the world are you trying to do? ntpq is NOT the way to get the
current time from the system. Use gettimeofday (linux) to get the current
time with sub microsecond latency. Do not use ntpq.
>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.
>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.
Please tell us what you are trying to do. You are telling us your solution
( which sounds really bad) instead of the problem you are trying to solve,
and then trying to convince the whole communtity to impliment your
>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?
Does anyone see any reason why it should be done.
>Obviously we hope you will allow us to be good Free Software citizens and let
>us drop the fork down the road. Will you?
You are of course free to drop it. Whether anyone will pick it up is
another question. Certainly you have not convinced me, but that is
irrelevant since I have absolutely no control over what goes into ntp. But
that may or may be indicative of how well you have convinced more
>Thanks in advance,
More information about the questions