Martin Burnicki wrote: > 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. >
Well any application that depends on using ntpq or any of its functionality is broken by definition unless it's used for monitoring purposes. >> 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. > > Martin 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. Danny _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
