[ntp:questions] No libntp.so

Unruh unruh-spam at physics.ubc.ca
Thu Aug 28 17:39:34 UTC 2008


kayhayen at gmx.de (Kay Hayen) writes:

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

You still have not told us what problem you are trying to solve. If you
want to know what time those various ntp devices have and whether they are
on time, just send them an ntp request packet and see what time they
deliver back to you. But please, tell us the problem you are trying to
solve. You are completely obsessed with your own solution, which sounds to
me at least to be highly suboptimal. And you want the whole community to
change to make your solution easy to impliment. Now that may be a valid
need and a valid solution, but at least to me it does not sound like it. 




More information about the questions mailing list