[ntp:questions] No libntp.so
unruh-spam at physics.ubc.ca
Thu Aug 28 17:46:09 UTC 2008
kayhayen at gmx.de (Kay Hayen) writes:
>Hello Mr. Unruh,
>> 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.
>Well, we are trying to get ntpd status information of a single node. I think
>we are using "peers", "assoc" and "rv" commands to learn the current offsets,
>sync states with peers, etc.
The ntpd status does not change for minutes to hours. Why in the world is
25ms of concern. If you want to know what time the far machine has you are
going about it in a very bad way. But I have no idea yet what you want.
>The execution of this seems to be 25ms in cases, that's much I believe for
>nothing at all. Which is why we want to use libntp.a and avoid to use ntpq at
>all for querying the information we seek.
>> >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
>Uhm, well you are right.
>We need to assess NTP status information. We consider the details of every
>peer of the system, reachability, jitter, etc.
And 25ms matters why?
>Ideally as it occurs with no delays. Ideally we would be able to poll() some
>file descriptor whenever something has changed for an ntpd. I don't think
>such an interface exists. Short of that we would check it with reasonable
>We need to do it for many hosts to calculate a "CLOCK" status for the host,
>and the clock status would e.g. be bad if an ntpd is synchronized to an
>internal host, but not one the allowed external hosts. There is a set of
>criterias subject to user configuration.
milliseconds or even seconds make no difference to this. No clock wanders
off time that rapidly.
>We need to be able to actively restrict NTP servers that are out bounds with
>offsets. Servers that e.g. mishandle a leap second and are 1 second off from
>that time on, or have other malfunctions, will be disabled that way.
Again milliseconds is irrelevant. And why not set up your own gps server
with external ones as backups.
>We need to publish the information for all hosts via SNMP.
>That's about it.
>I understand that ntpq could sort of be convinced to give out the information
>in reasonable time frames if we have it continously running as a child and
>get it to flush by using ptys.
>I also understand that ntpq simply uses libntp.a and decorates the results
>with some ASCII art that we would decode back. That's merely a source of bugs
>and uglyness. The ptys and extra process only introduces useless delays.
>> >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.
>Well, if there was an libntp.so, I would e.g. expect Python bindings to exist
>and the need for using ntpq in python-expect and parsing its output would
>simply go away entirely. Performance and ease of integration can only
>increase that way.
>I was asking for a reason why it is not so, because about everybody else in
>Free Software has an lib available. It's hard to find a server on the system
>without a lib package these days, isn't it?
>Reasons to not do it would only be things like "but we don't want a stable
>interface", etc. that is why I am asking, because it could well be that it's
>I am not trying to make your decisions.
>But certainly the first thing we looked for when we started was libntp.[a|so]
>in our Linux distribution, but it didn't exist. A check with search engines
>didn't reveal why this is so. It could simply be because nobody else cared
>(deeply enough) about it so far.
>> >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
>> influencial people.
>Let me be clear: I did not mean to fork the ntp code base in a public way. I
>can have libntp.a as it is now and can actually use it, in our own project
>(which will be Free Software later on), but that feels wrong.
>It's waste in two ways:
>First if we patch only for us in that way and compile ntp ourselves, others
>won't benefit from it. Second we track ntp upstream over and over and build
>code that is already on the target system again, just not accessible, because
>there are only binaries, no libs.
>What we are not asking is for NTP community to give up or change its goals. I
>don't want that, I couldn't achieve it. I just don't know them!
>We are offering our willingness to:
>a) Create patches that make the libntp.a and libntp.so (we are not yet ready
>with that, as we have other important milestones before we start this).
>b) Work to integrate them into your work.
>c) Work with distributors to change their packaging of ntp to take benefit of
>If NTP community says no to step b) we can choose a much easier way of solving
>a) because we don't need build the library in a tremendously portable way, as
>Lets say, I have narrowed this (in my mind) down to availablity of libntp.a
>and/or libntp.so in common ntp installations for ready access by our
>software. And my suspect is that due to the BSD-alike license normally
>everybody just silently takes the code.
>I believe older middleware from another vendor that I am familiar with did
>that probably, unless of course they implemented the RFC themselves. But both
>would be waste, and we want to be good Free Software citizens.
More information about the questions