[time-nuts] future NTP programs...
Magnus Danielson
magnus at rubidium.dyndns.org
Mon Nov 10 19:25:56 EST 2014
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
More information about the time-nuts
mailing list