[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