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

[Thomas Guyot-Sionnest]

> -----Original Message-----
> From: nagiosplug-devel-bounces at lists.sourceforge.net 
> [mailto:nagiosplug-devel-bounces at lists.sourceforge.net] On 
> Behalf Of sean finney
> Sent: April 5, 2007 13:09
> To: Nagios Plugin Development Mailing List
> Subject: Re: [Nagiosplug-devel] check_ntp (Was: Flight 
> 1.4.8,ready for boarding)
> 
> On Thu, 2007-04-05 at 09:29 -0400, Thomas Guyot-Sionnest wrote:
> > > 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'm talking about the host jitter (READVAR with assocID set to 0) and its
only peer's jitter (READVAR with the only possible assocID)

Not to be confounded with the jitter the Perl check_ntp used to get, which
looked like the jitter between the monitoring station and the checked host
over a round of ntp calls. I don't believe there's any practical use for
that unless the monitoring host is using that server for synchronization,
though it could use it's own server to check that (-h localhost). Maybe for
those running ntpdate instead of an ntp daemon, though when you don't care
that much about precision do you really care for jitter?


> > 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).

UDP is not a connection-oriented protocol. It will take anything suposedly
sent from the remote ip/port to the local ip/port and packet ordering is not
guarenteed. What if earlier in the plugin you decided that some packet was
not coming back, but some routing issues on the network made it come back a
few seconds later? What about the bug where I have to leave the socket open
in order to start on a new port, because It receive an odd packet in the
jitter section. The linked-list solution would just silently discard odd
packets.

Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3076 bytes
Desc: not available
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20070405/d091c5cd/attachment.bin>