[Nagiosplug-devel] check_ntp (Was: Flight 1.4.8, ready for boarding)

[sean finney]

On Thu, 2007-04-05 at 09:29 -0400, Thomas Guyot-Sionnest wrote:
> >> Right now it gets the first server listed in dns (while the offset
> >> function gets them all) and find the synchronization source. It then
> >> check the sync source; if there is none it will check all candidates.
> > 
> > right.  again to be filed under "behaves as before" wrt check_ntp and
> > ntpq/ntpdate.
> 
> So you're ok to check jitter on all servers?

on all servers resolving from the record for the sync source, yes.

> Yes, but I felt is was much safer to just try with jitter, then try
> dispersion if jitter doesn't work. There's many different version/forks
> of net daemons out there and it would be really difficult to behave
> correctly on all of them.

seems reasonable.  but i wonder whether thresholds for checking jitter
are practical for checking dispersion and vice versa.

> > so for clarity: with check_ntp -H host, should the jitter on the host be
> > calculated, or the jitter of its sync source / candidate sync sources be
> > checked?
> 
> You mean: check_ntp -H host -j x -k y
> 
> As without -j or -k jitter is not calculated.
> 
> Checking the host jitter or its sync source(s) is pretty much the same
> (ex if you have one peer both values are equal).

are they?  i thought jitter had to do with the level of variance from
the host clock to the time source, in which case it could be very
host-dependent.
 
> > i think i was looking at the offset_request function again, oops.
> > anyway, probably the same method could still be used, though the setup
> > might be a little more complicated if the total size results from a few
> > different gettaddrinfo calls.  is that what you were thinking of using
> > the linked list for?  i.e. the setup and not the actual i/o?
> 
> I was thinking of resolving the address once and putting them in an
> array. The linked list would contain some of the header fields on sent
> packets so that when we get a packet back we can match it. This is
> longer-term though so we'll see later.

but i still don't see why you need to store the header packets for
lookup purposes (esp in a linked list), when you already know implicitly
where the packets are coming from (i.e. which socket you're reading
from).

	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20070405/332c8c50/attachment.sig>