[ntp:questions] No libntp.so

Unruh unruh-spam at physics.ubc.ca
Thu Aug 28 18:02:13 UTC 2008

martin.burnicki at meinberg.de (Martin Burnicki) writes:

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

My suspicion is that are using those ntpq queries to try to figure out if
the remote machines are "on time". Ie they use ntpq to query the time on
the remote machine, and then read the time on their local machine to see if
the remote machine is out of time sync. Then 25ms would be a long time.
However, using ntpq to determine the time on the other machine is silly.

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

>For NTPv4 there's no RFC but an IEEE draft. See:

More information about the questions mailing list