Hello Kay, Kay Hayen wrote: > Hello Martin, > > thanks for the reply, you wrote: > >>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. > > We are using "ntpq -n" which makes a huge difference for the peers command > and > make all DNS lookups obsolete. We are also not using DNS on these machines, > but only a hosts file, so normally this couldn't play a role.
OK. However, if 25 milliseconds is still too long for other task you are running you should do this asynchronously anyway. >>>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. > > I have not come to fully understand where the code is that is executed when I > enter "peers", but it seemed that the encoding and decoding of packets could > be found there at least. Search the code for dopeers(), dogetpeers(), doprintpeers(). The packets returned from ntpd already contain some ASCII text with the desired data. > But checking now, the RFC 2553 is not the NTP one. Would you happen to know > if > the decoding/encoding of the packets are part of the library? I could not > identify it right now. This is mainly done in ntpq_subs.c which is not in the library. This is why I think it would not help you just to distribute libntp as a .so file. >>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. > > Can you point me to that work? It seems like we would want to contribute to > that effort then. > >>However, those calls may also block, so the basic requirement to call those >>functions from an own tread/task would be unchanged. > > One would hope that it could provide both kinds of APIs by allowing us to > poll > on the reply receiving socket. That's not normally very hard to refactor code > that waits for a reply to give back control and continue when the reply comes > in. Provided of course, the protocol allows questions and replies to be > matched by another criterion than sequence, can they? You should discuss this with the guy who's working on this. I'll ask him to contact you. BTW, I wonder why your post to which I'm just replying is not yet shown by the public news servers? >>>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. > > If it's only based on the fact that the NTP code isn't ready yet, we will be > happy as it seems that we can work with you to get it there. > > It seems I was overly optimistic when I saw the listing of libntp directory, > because it included an RFC in file name. Too bad that's not the NTP RFC. :-/ Right. The RFC for NTPv3 is 1305. See at the bottom of: http://www.meinberg.de/english/info/ntp.htm For NTPv4 there's no RFC but an IEEE draft. See: http://www.ietf.org/proceedings/05nov/ntp.html Best regards, Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
