So, I've been continuing to mess about with my own little sFlow to RRD utility (my needs are small, I'll take for Australia...) and, like ntop-4.0.3 have been using DERIVE with a min of 0 for the RRD, basing that on some of the text in the NOTE on COUNTER vs DERIVE in rrdcreate.1.
Now, that note appears to have been written in the time when 100BT was a "high speed" interface. I happened to be running a link-rate netperf UDP_STREAM test through a 1GbE switch port and getting sFlow counters from said switch. The switch was configured to send sFlow counter samples every 30 seconds. However, when I was graphing the octet counters out of the RRD, I noticed lots and lots of blank space, punctuated by the occasional pair of lines covering 30 seconds each. As it happens, DERIVE does not (by definition) handle counter wraps. As it also happens, my particular switch has a bug where the octet counters reported via sFlow are only 32 bits effectively rather than 64. As such, the octet counter was wrapping something like every 35 seconds. This meant there were long stretches where each 30 second sample interval had a counter wrap, and DERIVE (with a min of 0) was dutifully tossing those updates into the unknown bucket. Now, arguably, I should have been supplied with 64-bit counters from the sFlow agent, but if folks see periods of unexpected "no data" regions in their graphs, 32-bit counter wrap (say if supplied via SNMP and legacy MIB, or from an sFlow device broken in a manner similar to this one I'm using at the moment) coupled with ntop's use of DERIVE,min=0 may be the reason. rick jones _______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
