[ntp:questions] No libntp.so
kayhayen at gmx.de
Wed Aug 27 23:31:58 UTC 2008
> > 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
More information about the questions