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 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. 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? Thanks in advance, Kay Hayen _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
