I don't think so. First off, the rrd's themselves are 'averaged' - they're stored as rates (per second) on long (5 minute) intervals.
Second, netFlows increment counters, but the counters are accumulated until the various intervals expire for calculating 2nd order items such as throughput. Read through handleV5Flow() in plugins/netFlowPlugin.c - follow the calls to updateTrafficMatrix() and updatePacketCount() - ultimately all that's done with netFlow input is calls to incrementTrafficCounter(). The two key items, numPkts = ntohl(record->dPkts); and len =(Counter)ntohl(record->dOctets); are pulled out of the flow. So - unless your netFlow collector is averaging over very long periods - minutes or hours - whether you report 10 flows of 1 packet or 1 flow of 10 packets it's the same. (Internally, netFlow and sFlow are different - netFlow directly counts things, sFlow builds a fake packet and injects it into processPacket()). -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of Markus Rehbach > Sent: Saturday, February 28, 2004 10:54 AM > To: [EMAIL PROTECTED] > Subject: Re: [Ntop-dev] values in upToXYZPkts RRD graphs are too low > (about factor 10) (QDA9WTB?) > > > The frequency matters. Consider the case where a Netflow Emitter > is sending a > Netflow packet for every 'raw' packet it received. The value of > the packet > field in the netflow packet equals the packet size and is 100% correct. > Making the sampling time longer you will alway get the packet > size (packets/ > bytes) averaged. _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
