[rrd-users] bug in dealing with counter wrap in 1.4.3?

[Edward Lassotovitch]

You may want to use the bps MIB's instead, such as IfStatsInBitsPerSec and IfStatsOutBitsPerSec. They would be under your vendor's MIB's. They work a lot better and don't wrap. I'm graphing multi-gigabit speeds no problem with them.

From: rick.jones2 at hp.com
To: rrd-users at lists.oetiker.ch
Date: Tue, 14 Jun 2011 16:52:35 -0700
Subject: [rrd-users] bug in dealing with counter wrap in 1.4.3?

At the moment, I am working with a device that should be using 64-bit
wide counters in its report of octets via sFlow, but is only using 32
bits.  Through this device I am sending a constant stream of netperf
UDP_STREAM reporting a very steady 961 Mbit/s (and change, occasionally
it will report 960.97 Mbit/s) so I suspect the device is being driven at
link-rate.  It is reporting these counters every 30 seconds, link-rate 1
GbE networking should wrap a 32-bit octet counter in ~40 seconds, so I
believe I should never have more than one counter wrap per sampling
interval.  I am using a step size of one second.
 
I was seeing large gaps in my graphs so I isolated the one value  I was
looking at from the rest, and captured some data from the device and fed
it to an rrd created with:
 
rrdtool create test.rrd --start 1308092201 --step 1 DS:foo:DERIVE:60:0:U
RRA:AVERAGE:0.5:1:86400
 
fed it with the data I extracted from a tcpdump trace of the sFlow PDUs:
 
raj at tardy:~/rrdbug$ cat update.sh 
rrdtool update test.rrd 1308092202.610:441241050
rrdtool update test.rrd 1308092232.610:4141751743
rrdtool update test.rrd 1308092262.609:3546818048
rrdtool update test.rrd 1308092292.609:2952516367
rrdtool update test.rrd 1308092322.609:2357287750
rrdtool update test.rrd 1308092352.609:1762735341
rrdtool update test.rrd 1308092382.609:1168026482
rrdtool update test.rrd 1308092412.609:573080395
rrdtool update test.rrd 1308092442.609:4273817690
rrdtool update test.rrd 1308092472.608:3678028081
rrdtool update test.rrd 1308092502.608:3082845004
rrdtool update test.rrd 1308092532.608:2488508409
rrdtool update test.rrd 1308092562.608:1892937812
rrdtool update test.rrd 1308092592.608:1298202985
rrdtool update test.rrd 1308092622.608:703006246
rrdtool update test.rrd 1308092652.608:107385307
rrdtool update test.rrd 1308092682.607:3807847414
rrdtool update test.rrd 1308092712.607:3212758463
rrdtool update test.rrd 1308092742.607:2617461450
rrdtool update test.rrd 1308092772.607:2022995653
rrdtool update test.rrd 1308092802.607:1428422068
rrdtool update test.rrd 1308092832.607:833109777
rrdtool update test.rrd 1308092862.607:239454268
rrdtool update test.rrd 1308092892.607:3939282433
rrdtool update test.rrd 1308092922.606:3343962564
rrdtool update test.rrd 1308092952.606:2749615279
rrdtool update test.rrd 1308092982.606:2154394252
rrdtool update test.rrd 1308093012.606:1559964909
rrdtool update test.rrd 1308093042.606:965307748
rrdtool update test.rrd 1308093072.606:370349517
rrdtool update test.rrd 1308093102.606:4070642890
rrdtool update test.rrd 1308093132.606:3475575191
rrdtool update test.rrd 1308093162.605:2881212866
rrdtool update test.rrd 1308093192.605:2286174031
rrdtool update test.rrd 1308093222.605:1691311682
rrdtool update test.rrd 1308093252.605:1097016331
rrdtool update test.rrd 1308093282.605:502274162
rrdtool update test.rrd 1308093312.605:4201809009
rrdtool update test.rrd 1308093342.605:3606613788
rrdtool update test.rrd 1308093372.604:3012392733
rrdtool update test.rrd 1308093402.604:2417665658
 
and then graphed that:
 
rrdtool graph graph.png  --end 1308093373 --start 1308092202 -w 1000 -h
400  --step 1 -t "30 Second Counter Samples" -v "Octets/s"
--full-size-mode DEF:bar=test.rrd:foo:AVERAGE LINE2:bar#FF0000
 
The resulting graph is attached.  Is there perhaps some issue in the
wrap code that results in the drop-outs?  FWIW, I appear to see the same
behaviour if I use COUNTER rather than DERIVE.
 
rick jones

_______________________________________________
rrd-users mailing list
rrd-users at lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20110615/4c9086e6/attachment.htm