[ntp:questions] No libntp.so

Kay Hayen kayhayen at gmx.de
Wed Aug 27 23:31:58 UTC 2008

Hello Uwe,

> > Like I said, we know, pipes are not suited at all for the task. I must
> > admit, I was not aware of the issue before, I was under impression, we
> > could simply set stdin/stdout to no buffering, but it appears for pipes
> > that is not an option, and thinking about it, pipes really need to
> > buffer.
> MY guess is you don't know enough about unix(like) systems to build any
> meaningfull software with the stringent requirements linked to your
> applications environment.
> You may want to read up on pipes, ptys and associated buffering.

I have no idea what triggered this.

> > We were considering to use an expect wrapper (python-expect) to channel
> > the data to us, and it would certainly improve the results. But I see no
> > reason to use that workaround at all. Why should we make ntpq draw ASCII
> > art only to parse it and endure the changes between your releases?
> I personally don't release anything.

I didn't say so. In German I would have said "Änderungen zwischen Euren 
Releases" and it would have been clear that I didn't mean you personally, of 
I did course not. In English it happens to be the same word, "your" for one 
person or a group, sorry if I was not clear enough.

> > What we really want to do is to use libntp to send out some queries to
> > the ntpd servers we monitor (10 of them) and async wait for replies to
> > process them immediately and with minimal latency.
> >
> >>And you seem to work through your jobs in a serial way? Use select().
> >
> > Well, yes of course. Short of using expect, we ran ntpq each time anew
> > and fetched its response immediately. That was good enough for a
> > prototype that re-used parsing code that we already have for ntpq output,
> > but now we would like to do better.
> well parsing any output with expect is trivial.
> I wonder why Eurocontrol is well served with tcl.

And the point of it is what? I didn't say anything against tcl, nor would I, 
nor could I. It's a fine tool. 

But given the choice, we would prefer to use a libntp. What's wrong with that, 
except that you don't find it necessary? On the pro-side there is:

a) A significant reduction in lines of code used which can only lead to less 
b) The CPU used to make one set of queries will be lower potentially enabling 
a higher frequency of checks achieving lower latency in detecting NTP 

Best regards,
Kay Hayen

More information about the questions mailing list