[rrd-developers] Re: Delay in gathering stats, and perhaps how to deal with them

[steve rader]

 > > The tact I'm taking now is to just fudge the update times:
 > > since I put a 5 second timeout on executing my collection
 > > scripts, the fudge factor is less than 1.6% (5/300).  If the
 > > network is hosed enough to cause a five second, graphing NaN
 > > is a-okay.
 
 > From: Alex van den Bogaerdt
 > And this delay is a problem that keeps popping up. I also ha(d|ve)
 > this problem. Note that it is not only the network, it can also
 > be the host itself (more likely in my case, to be exact).
 
 > I suppose common practice is to measure the delay and divide
 > it in two to guess the time that the device responded to the
 > snmpget. Is this realistic ? 

I thought about this idea and decided it's no good.  It assumes
that the latency in getting the data is equally caused by the
host, the net, the router, etc.  In reality, I doubt this is
ever true.

 > Perhaps there is a better way:
 > I've been playing with snmpget and tcpdump and it looks like it
 > is possible to query more than one OID simultaniously. Would the
 > following not be any good ?

IMO, yes for the data and no for the time stamp...

Getting all OIDs together means the data can be considered "coupled"
and thus put into the RRD together at the same time stamp.  (In other
words, it avoids having to use two RRDs for if[In|Out]Octets.)

But I don't think using system.sysUpTime.0 is a really Good Thing.
It's vaguely possible for clock-skew to cause some ugly problems.
I'd rather not have the accuracy of my data dependant on correctly
installing, configuring and managing ntp or rdate or whatever.

later
steve
- - -
systems guy
wiscnet.net

--
* To unsubscribe from the rrd-developers mailing list, send a message with the
  subject: unsubscribe to rrd-developers-request at list.ee.ethz.ch