[rrd-users] Need help understanding consolidation

I'm having trouble understanding how data points are being consolidated into
an RRA in a particular circumstance. I have 3 counters I want to store in a
single RRD (I plan to use a COMPUTE, but I've left it out of this example).
The counter data is delivered to me by a router, with 1 counter
(ifHCInOctets) being delivered at a different time than the other 2
(greenBytes, redBytes).
If I update only ifHCInOctets, or only greenBytes and redBytes, the results
are what I expect. However, if I update all three, I get all NaNs. I
expected with the xff set to 0.99 that 1 known data point and 1 unknown data
point during the step would consolidate into a known data point.
Interestingly, if I substitute COUNTER with GAUGE, I get values, so I
presume it is a nuance of consolidation with respect to the rate
calculation.

Example 1:
----------------
rrdtool create x.rrd -b 1161180810 -s 300 DS:ifHCInOctets:COUNTER:600:0:U
DS:greenBytes:COUNTER:600:0:U DS:redBytes:COUNTER:600:0:U
RRA:AVERAGE:0.99:1:2304


rrdtool updatev x.rrd -t ifHCInOctets 1161180811:5303133556
rrdtool updatev x.rrd -t greenBytes:redBytes 1161180822:5562882597:0
rrdtool updatev x.rrd -t ifHCInOctets 1161181114:5304677809
rrdtool updatev x.rrd -t greenBytes:redBytes 1161181124:5564615866:0
rrdtool updatev x.rrd -t ifHCInOctets 1161181417:5306928049
rrdtool updatev x.rrd -t greenBytes:redBytes 1161181426:5566896441:0

Output:
-----------
return_value = 0
return_value = 0
return_value = 0
[1161180900]RRA[AVERAGE][1]DS[ifHCInOctets] = NaN
[1161180900]RRA[AVERAGE][1]DS[greenBytes] = NaN
[1161180900]RRA[AVERAGE][1]DS[redBytes] = NaN
return_value = 0
return_value = 0
[1161181200]RRA[AVERAGE][1]DS[ifHCInOctets] = NaN
[1161181200]RRA[AVERAGE][1]DS[greenBytes] = NaN
[1161181200]RRA[AVERAGE][1]DS[redBytes] = NaN
return_value = 0

So, I made the assumption that leaving a DS value as "unknown" caused the CF
to return NaN regardless of the xff. Following this line of thinking, I set
the RRA's CF to MAX instead of AVERAGE, and used 0s in place of the unknown
values. This got rid of the NaNs, but introduced another problem.

Example 2:
----------------
rrdtool create x.rrd -b 1161180810 -s 300 DS:ifHCInOctets:COUNTER:600:0:U
DS:greenBytes:COUNTER:600:0:U DS:redBytes:COUNTER:600:0:U RRA:MAX:0.99:1:2304


rrdtool updatev x.rrd 1161180811:5303133556:0:0
rrdtool updatev x.rrd 1161180822:0:5562882597:0
rrdtool updatev x.rrd 1161181114:5304677809:0:0
rrdtool updatev x.rrd 1161181124:0:5564615866:0
rrdtool updatev x.rrd 1161181417:5306928049:0:0
rrdtool updatev x.rrd 1161181426:0:5566896441:0

Output:
-----------
return_value = 0
return_value = 0
return_value = 0
[1161180900]RRA[MAX][1]DS[ifHCInOctets] = 2.0726678730e+17
[1161180900]RRA[MAX][1]DS[greenBytes] = 5.5365785706e+16
[1161180900]RRA[MAX][1]DS[redBytes] = 0.0000000000e+00
return_value = 0
return_value = 0
[1161181200]RRA[MAX][1]DS[ifHCInOctets] = 6.1489146912e+16
[1161181200]RRA[MAX][1]DS[greenBytes] = 6.1013367128e+16
[1161181200]RRA[MAX][1]DS[redBytes] = 0.0000000000e+00
return_value = 0

Those numbers are much larger than I expected. Can someone explain what's
going on and, if possible, propose a work-around that keeps the counters in
the same RRD so I can add a COMPUTE?

I am using rrdtool 1.2.15.

Thanks,
Jeremy Hough


--
Unsubscribe mailto:rrd-users-request@list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-users-request@list.ee.ethz.ch?subject=help
Archive http://lists.ee.ethz.ch/rrd-users
WebAdmin http://lists.ee.ethz.ch/lsg2.cgi