[ntp:questions] No libntp.so

Kay Hayen kayhayen at gmx.de
Wed Aug 27 22:32:00 UTC 2008


Hello Mr. Unruh,

Am Dienstag, 26. August 2008 21:31:00 schrieb Unruh:
> kayhayen at gmx.de (Kay Hayen) writes:
> >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).
>
> Why not fflush it? And why would you need lack of latency. It is a report.
> It is not time critical or should not be. What you are doing sounds bizzare
> to me.

I don't think it's a lack of our sides to fflush. Without a tty, ntpq itself 
will not flush I think. So when using pipes, we have to close stdin, which 
will make it flush its output due to exiting.

And to not have a visible zombie (for too long), we need to wait for its exit 
code too.

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

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.

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

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.

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.

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

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

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

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.

Best regards,
Kay Hayen



More information about the questions mailing list