[time-nuts] future NTP programs...

Neil Schroeder gigneil at gmail.com
Mon Nov 10 20:09:52 EST 2014

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 <magnus at rubidium.dyndns.org>

> Poul-Henning,
> On 11/11/2014 01:15 AM, Poul-Henning Kamp wrote:
>> --------
>> In message <546152AC.8090307 at 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 at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.

More information about the time-nuts mailing list