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

[Alex van den Bogaerdt]

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

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 ? 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 ?

[alex at host /home/alex]$ snmpget cisco public \
	.1.3.6.1.2.1.2.2.1.10.1 \
	.1.3.6.1.2.1.2.2.1.16.1 \
	.1.3.6.1.2.1.1.3.0
interfaces.ifTable.ifEntry.ifInOctets.1 = 130283627
interfaces.ifTable.ifEntry.ifOutOctets.1 = 39969136
system.sysUpTime.0 = Timeticks: (1097621419) 127 days, 0:56:54

Output from tcpdump: (BTW: "thuis" means at home :-)

00:22:20.764794 arp-cisco arp-cisco loopback 60:
                         0000 0100 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000
00:22:21.994831 host.thuis.1254 > cisco.thuis.snmp: GetRequest(9)[|snmp]
00:22:22.024832 cisco.thuis.snmp > host.thuis.1254: GetResponse(11)
00:22:30.036796 arp-cisco arp-cisco loopback 60:
                         0000 0100 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000

AFAIK this is three OIDs in one packet. If we use timeticks and
use this to calculate the real time delta, wouldn't this be much
more accurate ?

PRO: You will know the exact delta in both time and counters.
CON: You won't know the exact time that this happens. 

IMO it is better to have an accurate rate at the wrong time (a few
tenths of a second, maybe a whole second) than a wrong rate at exactly
the right time.

Regards,
Alex

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