[ntp:questions] No libntp.so

Kay Hayen kayhayen at gmx.de
Wed Aug 27 21:41:02 UTC 2008


Hello Uwe,

thank you for your reply. :-)

Am Dienstag, 26. August 2008 22:29:03 schrieb Uwe Klein:
> Kay Hayen wrote:
> > Hello NTP-World :-),
> >
> > we are implementing a NTP supervision for our ATC middleware. Initially
> > we are
>
> ATC as in air traffic control?

Yes that's right. I have this understanding that NTP was invented in the 
field, wasn't it?

> > 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).
> >
> > 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.
>
> First think about what ntpq has to do during startup. Then think again ;-)

Starting ntpq does to seem to do nothing at all. When we do the peers command, 
I saw it can be slow without -n option (checking with tshark), but we are 
using that. 

I don't think we want to use ntpq at all though.

> On the piping issue:
> Thats what ptys are for. You would have ntpq as a running process that can
> be queried at any time.
> You run into nonlinebuffering issues on stdin and stdout due to both
> not being ttys.

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.

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?

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.

I don't think we would have done ntpq parsing had it not been that this code 
existed for historic reasons.

> > 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 may want to look around to how these people solved their probs:
> 	http://wiki.tcl.tk/15535

That part of EUROCONTROL (and them in general) is well known to me. As 
libntp.a seems to offer all it takes, this question is more about how to get 
access to it in sane way.

Best regards,
Kay Hayen




More information about the questions mailing list