Re: [time-nuts] future NTP programs...
In message 54615794.3040...@rubidium.dyndns.org, Magnus Danielson writes: I'm just saying that the NTP processing and the NTP monitoring may not need to run by the same daemon necessarily. As the Varnish architecture shows, I'm fully in agreement with this. I should also add that one of the reasons I don't like the control mode packets is that they are complex. I have no issues with handling the standard 48 byte fixed format, no strings NTP timing packets in a root-process, but in todays environment it would not be OK to design a daemon which handles the crypto stuff or the control packets in a root-process, those should go in a sandbox. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
it would not be OK to design a daemon which handles the crypto stuff or the control packets in a root-process, those should go in a sandbox. Absolutely agree, in my previous life in the data security arena (crypto, data security, white hat tester etc..), doing that sort of thing in a privileged process or similar (e.g. kernel) was a seriously discouraged - far too great a risk of compromise. Keep it all in a user state process with NO write access to anything except the communications port (serial / UDP / TCP / w.h.y.) it is talking on. Regards, David Partridge ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
- that there is (eventually) a Windows implementation. I'm writing the code to be as portable as I can make it, but I have neither Windows machines nor clue how to program for their kernel-time-api. - that it responds to ntpq -pn and ntpq -crv commands so that it can be easily remotely monitored. The jury is still out on the control protocol. To be honest I don't much like it from a security point of view, and the parameters of my clock control algorithm may not map well into its datafields. Time will show... Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 == Yes, I can appreciate the Windows problems. We have more than a thousand clients running the reference NTP as ported by Meinberg very happily, but if there were a better-performing implementation that would be nice to have. Personally, I feel that the ability to monitor the workings of an NTP implementation remotely is an important feature of the (present) software. I can run on one system a single monitoring program which then checks NTP running on Windows, Linux and FreeBSD systems using exactly the same over the wire ntpq commands. Perhaps you can return dummy values where your algorithm differs? The ability to know lock status, offset and jitter (ntpq -crv) is useful for longer term checking, and the * in ntpq -p helpful for a response to a quick-look is it working? interrogation. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
In message 43713AD334A7485B8B0CCED799C6C19A@Alta, David J Taylor writes: Personally, I feel that the ability to monitor the workings of an NTP implementation remotely is an important feature of the (present) software. So, this is one thing I really don't understand... You can monitor all your clients from your server if you want to, by looing at the timestamp the client sends you. I implemented this feature in NTPns over a decade ago (see below) Why on Earth would anybody prefer to monitor it on each client separately instead of getting one central unified view ? Yes, of course you should be able to tell if your timekeeping is good on the local machine, but I don't think the control-mode NTP packets is a good idea. Poul-Henning NTPns show ntpv4 0 partner IP number port leap v m s p P offset refid Max partners: 1 total ours others partners2458855 1603 partners good 1874843 1031 partners bad 584 12572 partners 1s323 5318 partners 1s470 10460 partners 100ms 367 37330 partners 10ms 521195326 partners 1ms 777608169 NTPns show ntpv4 0 partner bad IP number port leap v m s p P offset refid 0.0.38.89 123 no 3 3 0 0 0 -0.166501269 [] 0.0.62.87 123 no 3 3 0 0 0 -0.755177799 [] 0.0.10.55 123 no 1 3 0 0 0 -0.397674942 [] 0.0.240.197123 unk 4 3 0 6 -19-3308.8 [INIT] 0.0.227.61 123 no 4 3 0 0 0 -3.024952149 [] 0.0.125.188123 no 3 3 0 0 00.185896998 [] 0.0.145.174123 no 3 3 0 0 00.465722434 [] 0.0.196.133123 no 3 3 0 0 0 -0.180700990 [] 0.0.16.190 123 unk 3 3 0 10 -6 -0.520566284 [] 0.0.68.26 123 no 3 3 8 6 -180.345824138 [CHU_AUDIO#1] [...] IP numbers obfuscated to protect the incompetent... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
From: Poul-Henning Kamp [] Personally, I feel that the ability to monitor the workings of an NTP implementation remotely is an important feature of the (present) software. So, this is one thing I really don't understand... You can monitor all your clients from your server if you want to, by looing at the timestamp the client sends you. I implemented this feature in NTPns over a decade ago (see below) Why on Earth would anybody prefer to monitor it on each client separately instead of getting one central unified view ? Yes, of course you should be able to tell if your timekeeping is good on the local machine, but I don't think the control-mode NTP packets is a good idea. Poul-Henning === Poul-Henning, But if I understand NTPns correctly (I didn't know about it, by the way), it does not address the task I have in mind. I don't want to monitor clients from my server. I don't want to monitor servers from my client. I want to be able to monitor a number of servers from a central monitoring point (which might not even be running NTP), and using ntpq with its different options is, for me, an ideal way to do that. I use Perl scripts to interpret the output and plot it with MRTG. What I'm doing at the moment happens to run on Windows, but as it's a combination of ntpq, Perl and MRTG is could be run almost anywhere Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
In message 647BB61DCE1F4679A45CD5C1DB1FE963@Alta, David J Taylor writes: I want to be able to monitor a number of servers from a central monitoring point (which might not even be running NTP), and using ntpq with its different options is, for me, an ideal way to do that. First of all, I'm focusing on the client software right now. That said: It goes without saying that monitoring servers is a different ball-game than monitoring clients. And no, I still don't like the ntpq stuff, because it cannot express the kind of things you'll want to monitor on a server, if you are serious about running it: How many clients report us as their REFID (is there something horribly wrong in a firewall somewhere ?) How many satelites does my GPS see ? And so on... How I'll doing the monitoring once I get to the server software remains to be seen, but it is very likely to involve a CLI interface and possibly a shared memory state Pretty much like Varnish ... feel free to wonder why ? :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
Poul-Henning Kamp writes: In message 0AA8645271A94DF3968C90FE6BF94276@Alta, David J Taylor writes: - that there is (eventually) a Windows implementation. I'm writing the code to be as portable as I can make it, but I have neither Windows machines nor clue how to program for their kernel-time-api. We should talk about it - there are some options and opportunities there. H ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
David and Poul-Henning, On 11/10/2014 10:34 AM, Poul-Henning Kamp wrote: In message 647BB61DCE1F4679A45CD5C1DB1FE963@Alta, David J Taylor writes: I want to be able to monitor a number of servers from a central monitoring point (which might not even be running NTP), and using ntpq with its different options is, for me, an ideal way to do that. First of all, I'm focusing on the client software right now. That said: It goes without saying that monitoring servers is a different ball-game than monitoring clients. And no, I still don't like the ntpq stuff, because it cannot express the kind of things you'll want to monitor on a server, if you are serious about running it: How many clients report us as their REFID (is there something horribly wrong in a firewall somewhere ?) How many satelites does my GPS see ? And so on... How I'll doing the monitoring once I get to the server software remains to be seen, but it is very likely to involve a CLI interface and possibly a shared memory state Pretty much like Varnish ... feel free to wonder why ? :-) I think it is fair to consider that over time, we need to revisit how things was designed and make changes. It might be better to run a separate daemon for the monitoring protocol, and it could be providing the traditional monitoring protocol or something new, or both. Monitoring as such is an important task, and some of the NTP clients might be servers in other contexts, and then it makes sense to monitor that they got their NTP time into shape. There is however many ways to slice that fish. Cheers, Magnus ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
In message 546152ac.8090...@rubidium.dyndns.org, Magnus Danielson writes:
Monitoring as such is an important task, and some of the NTP clients
might be servers in other contexts, and then it makes sense to monitor
that they got their NTP time into shape.
For which there has existed a system call for 20 years now:
ntp_gettime() has as argument a struct ntptimeval * with the following
members:
struct ntptimeval {
struct timeval time;/* current time (ro) */
long maxerror; /* maximum error (us) (ro) */
long esterror; /* estimated error (us) (ro) */
};
These have the following meaning:
time Current time (read-only).
maxerror Maximum error in microseconds (read-only).
esterror Estimated error in microseconds (read-only).
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] future NTP programs...
Poul-Henning,
On 11/11/2014 01:15 AM, Poul-Henning Kamp wrote:
In message 546152ac.8090...@rubidium.dyndns.org, Magnus Danielson writes:
Monitoring as such is an important task, and some of the NTP clients
might be servers in other contexts, and then it makes sense to monitor
that they got their NTP time into shape.
For which there has existed a system call for 20 years now:
ntp_gettime() has as argument a struct ntptimeval * with the following
members:
struct ntptimeval {
struct timeval time;/* current time (ro) */
long maxerror; /* maximum error (us) (ro) */
long esterror; /* estimated error (us) (ro) */
};
These have the following meaning:
time Current time (read-only).
maxerror Maximum error in microseconds (read-only).
esterror Estimated error in microseconds (read-only).
Sure. So that's what another daemon could be pulling out.
I'm just saying that the NTP processing and the NTP monitoring may not
need to run by the same daemon necessarily, just because we did that in
the past. Pulling things from the kernel provide more isolation, and the
monitor daemon can have special code to handle security issues of
monitoring, without making the processing dito suffer from it, beyond
making sure the data is available somewhere.
Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] future NTP programs...
I don't think ntp requires nor should have anything like a dedicated multi
system monitoring platform of its own.
The fact is that today's modern data collection methods are more than
adequate - ntpd need only store its values in an accessible place and
a graphite agent or ajna or your choice of robust system data mining tools
can scrape them regularly and store them for posterity.
A server-local cli infrastructure is clearly invaluable to the
troubleshooting process. But overall health monitoring is a wheel not in
need of an overhaul
On Monday, November 10, 2014, Magnus Danielson mag...@rubidium.dyndns.org
wrote:
Poul-Henning,
On 11/11/2014 01:15 AM, Poul-Henning Kamp wrote:
In message 546152ac.8090...@rubidium.dyndns.org, Magnus Danielson
writes:
Monitoring as such is an important task, and some of the NTP clients
might be servers in other contexts, and then it makes sense to monitor
that they got their NTP time into shape.
For which there has existed a system call for 20 years now:
ntp_gettime() has as argument a struct ntptimeval * with the
following
members:
struct ntptimeval {
struct timeval time;/* current time (ro) */
long maxerror; /* maximum error (us) (ro) */
long esterror; /* estimated error (us) (ro) */
};
These have the following meaning:
time Current time (read-only).
maxerror Maximum error in microseconds (read-only).
esterror Estimated error in microseconds (read-only).
Sure. So that's what another daemon could be pulling out.
I'm just saying that the NTP processing and the NTP monitoring may not
need to run by the same daemon necessarily, just because we did that in the
past. Pulling things from the kernel provide more isolation, and the
monitor daemon can have special code to handle security issues of
monitoring, without making the processing dito suffer from it, beyond
making sure the data is available somewhere.
Cheers,
Magnus
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] future NTP programs...
I'm just saying that the NTP processing and the NTP monitoring may not need to run by the same daemon necessarily, just because we did that in the past. Pulling things from the kernel provide more isolation, and the monitor daemon can have special code to handle security issues of monitoring, without making the processing dito suffer from it, beyond making sure the data is available somewhere. Because once you get past the simplest item you can monitor, the time NTP thinks it is. Then the only process that would have the informations ntpd. For example if you want to know the round rip ping time from some peer to your server then what can you do but ask the server? Mostly the thinks you monitor are NTP internal states and statistics. -- Chris Albertson Redondo Beach, California ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
Poul-Henning Kamp writes:
In message 546152ac.8090...@rubidium.dyndns.org, Magnus Danielson writes:
Monitoring as such is an important task, and some of the NTP clients
might be servers in other contexts, and then it makes sense to monitor
that they got their NTP time into shape.
For which there has existed a system call for 20 years now:
ntp_gettime() has as argument a struct ntptimeval * with the following
members:
struct ntptimeval {
struct timeval time;/* current time (ro) */
long maxerror; /* maximum error (us) (ro) */
long esterror; /* estimated error (us) (ro) */
};
These have the following meaning:
time Current time (read-only).
maxerror Maximum error in microseconds (read-only).
esterror Estimated error in microseconds (read-only).
And those fields have value, and they are not enough. The aim of
NTF's General Timestamp API is to have a timestamp with enough values
in it.
--
Harlan Stenn st...@ntp.org
http://networktimefoundation.org - be a member!
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
[time-nuts] future NTP programs...
In message bf75ef8568d7310a05437461dac9cb87.squir...@webmail.lysator.liu.se, =?iso-8859-1?Q?=22Bj=F6rn_Gabrielsson=22?= writes: Nevertheless I was a bit surprised that the computer continued to serve time claiming to be a S1-server, even if both local refclock and a number of external S1-servers said time was false. I dont know if recent ntpd and operating system versions still have this problem. Yeah, this is the kind of shit you have to put up with when your time-server source code is 100+ KLOC and has gotten to that size by lets just add this feature methodologies. Poul-Henning, for the updated server with local refclock, have you elaborated over My first target is a daemon for clients, that's the most efficient way to eliminate as many KLOC-executions from the world as possible as fast as possible. After that, the intent is to reuse the same components also for S2+ slave servers, and later again S1 servers. But the target right here and now is clients only. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
From: Poul-Henning Kamp [] My first target is a daemon for clients, that's the most efficient way to eliminate as many KLOC-executions from the world as possible as fast as possible. After that, the intent is to reuse the same components also for S2+ slave servers, and later again S1 servers. But the target right here and now is clients only. == Poul-Henning, I would like to see two things in a new client: - that there is (eventually) a Windows implementation. - that it responds to ntpq -pn and ntpq -crv commands so that it can be easily remotely monitored. Cheers, David -- SatSignal Software - Quality software written to your requirements Web: http://www.satsignal.eu Email: david-tay...@blueyonder.co.uk ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] future NTP programs...
In message 0AA8645271A94DF3968C90FE6BF94276@Alta, David J Taylor writes: - that there is (eventually) a Windows implementation. I'm writing the code to be as portable as I can make it, but I have neither Windows machines nor clue how to program for their kernel-time-api. - that it responds to ntpq -pn and ntpq -crv commands so that it can be easily remotely monitored. The jury is still out on the control protocol. To be honest I don't much like it from a security point of view, and the parameters of my clock control algorithm may not map well into its datafields. Time will show... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
