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).
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.
As we would like do other important stuff in the same process, we would like to do that faster. So I had a look at the source and found that ntpq is using a libntp.a that nobody seems to package though. There is no libntp.so either, we had searched for those initially, but no luck.
Our aims can be realized (and must be short term it seems) with a fork of your work that builds a shared library for use in our software. While that is workable, it is also bad thing to do in the first place.
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.
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?
Obviously we hope you will allow us to be good Free Software citizens and let us drop the fork down the road. Will you?
kayha...@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.
>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.
>As we would like do other important stuff in the same process, we would like >to do that faster. So I had a look at the source and found that ntpq is using >a libntp.a that nobody seems to package though. There is no libntp.so either, >we had searched for those initially, but no luck. >Our aims can be realized (and must be short term it seems) with a fork of your >work that builds a shared library for use in our software. While that is >workable, it is also bad thing to do in the first place. >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.
>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.
>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.
> we are implementing a NTP supervision for our ATC middleware. Initially we are
ATC as in air traffic control?
> 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 ;-)
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.
And you seem to work through your jobs in a serial way? Use select().
> Obviously we hope you will allow us to be good Free Software citizens and let > us drop the fork down the road. Will you?
> 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).
> 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.
As mentioned in another reply it depends on what ntpq has to do during those 25 milliseconds. Please be aware that this may include DNS lookups which might fail, so the the call would be take until the DNS lookup times out.
A proper approch would be to start a thread or task which would do the ntpq stuff asynchrounously and report the results to your main application when the reply has become available.
> As we would like do other important stuff in the same process, we would > like to do that faster. So I had a look at the source and found that ntpq > is using a libntp.a that nobody seems to package though. There is no > libntp.so either, we had searched for those initially, but no luck.
Libntp just contains a couple of functions which are shared between several programs of the NTP package, e.g. ntpd, ntpq and others. It is used during the build process of the package in order to save compiule time.
Even if you would be made available als shared object file it would not provide the full ntpq functionality.
> Our aims can be realized (and must be short term it seems) with a fork of > your work that builds a shared library for use in our software. While that > is workable, it is also bad thing to do in the first place.
> 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.
IMHO it would not make much sense to provide the existing libntp as shared object library. There is some ongoing work which will encapsulate the ntpq functionality in a shared object library, so it would be easier to use from an own application.
However, those calls may also block, so the basic requirement to call those functions from an own tread/task would be unchanged.
> 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?
> Obviously we hope you will allow us to be good Free Software citizens and > let us drop the fork down the road. Will you?
The question is not basically whether a patch is accepted. In the first place the question is whether a patch makes sense at all. As already mentioned above I think it does not much sense just to provide libntp as .so file.
In article <200808260659.13498.kayha...@gmx.de>, kayha...@gmx.de (Kay Hayen) wrote:
> 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).
What exactly is "NTP supervision"? What problem does it solve?
>>As mentioned in another reply it depends on what ntpq has to do during >>those 25 milliseconds. Please be aware that this may include DNS lookups >>which might fail, so the the call would be take until the DNS lookup times >>out.
> We are using "ntpq -n" which makes a huge difference for the peers command and > make all DNS lookups obsolete. We are also not using DNS on these machines, > but only a hosts file, so normally this couldn't play a role.
OK. However, if 25 milliseconds is still too long for other task you are running you should do this asynchronously anyway.
>>>As we would like do other important stuff in the same process, we would >>>like to do that faster. So I had a look at the source and found that ntpq >>>is using a libntp.a that nobody seems to package though. There is no >>>libntp.so either, we had searched for those initially, but no luck. >>Libntp just contains a couple of functions which are shared between several >>programs of the NTP package, e.g. ntpd, ntpq and others. It is used during >>the build process of the package in order to save compiule time.
>>Even if you would be made available als shared object file it would not >>provide the full ntpq functionality.
> I have not come to fully understand where the code is that is executed when I > enter "peers", but it seemed that the encoding and decoding of packets could > be found there at least.
Search the code for dopeers(), dogetpeers(), doprintpeers(). The packets returned from ntpd already contain some ASCII text with the desired data.
> But checking now, the RFC 2553 is not the NTP one. Would you happen to know if > the decoding/encoding of the packets are part of the library? I could not > identify it right now.
This is mainly done in ntpq_subs.c which is not in the library. This is why I think it would not help you just to distribute libntp as a .so file.
>>IMHO it would not make much sense to provide the existing libntp as shared >>object library. There is some ongoing work which will encapsulate the ntpq >>functionality in a shared object library, so it would be easier to use from >>an own application.
> Can you point me to that work? It seems like we would want to contribute to > that effort then.
>>However, those calls may also block, so the basic requirement to call those >>functions from an own tread/task would be unchanged.
> One would hope that it could provide both kinds of APIs by allowing us to poll > on the reply receiving socket. That's not normally very hard to refactor code > that waits for a reply to give back control and continue when the reply comes > in. Provided of course, the protocol allows questions and replies to be > matched by another criterion than sequence, can they?
You should discuss this with the guy who's working on this. I'll ask him to contact you. BTW, I wonder why your post to which I'm just replying is not yet shown by the public news servers?
>>>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?
>>>Obviously we hope you will allow us to be good Free Software citizens and >>>let us drop the fork down the road. Will you? >>The question is not basically whether a patch is accepted. In the first >>place the question is whether a patch makes sense at all. As already >>mentioned above I think it does not much sense just to provide libntp >>as .so file.
> If it's only based on the fact that the NTP code isn't ready yet, we will be > happy as it seems that we can work with you to get it there.
> It seems I was overly optimistic when I saw the listing of libntp directory, > because it included an RFC in file name. Too bad that's not the NTP RFC. :-/
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.
> >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.
> thank you for your reply. :-) > Yes that's right. I have this understanding that NTP was invented in the > field, wasn't it?
David Mills "invented" ntp in 1985 for authoritative time distribution and syncing of machines. Notice "time" and "authoritative".
>>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.
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.
> 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.
> 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.
G! uwe
-- Uwe Klein [mailto:ukl...@klein-messgeraete.de] KLEIN MESSGERAETE Habertwedt 1 D-24376 Groedersby b. Kappeln, GERMANY phone: +49 4642 920 123 FAX: +49 4642 920 125
