Replace 'value of packet' with 'value of byte' and 'packet/bytes' with 'bytes/
packets'. Sorry.
On Saturday 28 February 2004 17:53, Markus Rehbach wrote:
> 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.
>
> On Saturday 28 February 2004 13:51, Burton M. Strauss III wrote:
> > What do I think? I think you don't quite understand netFlow
> >
> > 1) The frequency of netFlow export shouldn't matter. netFlow is sending
> > you ((src),(dst),(pkt),(bytes)). If you delay the export, all the sender
> > does is collapse more packets - i.e. pkt > 1.
> >
> > But you still get the flow and it gets stored into the normal ntop
> > counters. See handleV5Flow() in plugins/rrdPlugin.c -- look for the
> > setting of len (from record->dOctets) and then the
> > incrementTrafficCounter() calls.
> >
> > Then the normal rrd loop takes over and periodically dumps the counters
> > into the rrds.
> >
> >
> > I think you and Bill Richardson need to figure out which value is right
> > and which is wrong. It sure sounds like it could be the same basic
> > problem, See his PR QDA9WTB stuff...
> >
> >
> > Bill: Reading the code, there clearly are two different paths taken
> > between the domain and hosts stats. More precisely, there are a number
> > of conditions that would cause the host data not to be stored, while the
> > domain data is pretty much unconditional. Compare the blocks in
> > plugins/rrdPlugin.c: if(dumpDomains) {} 1684ff vs. if(dumpHosts) {} at
> > 1801ff
> >
> > Key differences:
> >
> > dumpDomains uses the now standard loop:
> >
> > // walk through all hosts, getting their domain names and
> > counting stats
> > for (el = getFirstHost(devIdx);
> > el != NULL; el = getNextHost(devIdx, el)) {
> > vs.
> >
> > for(i=1; i<myGlobals.device[devIdx].actualHashSize; i++) {
> > HostTraffic *el = myGlobals.device[devIdx].hash_hostTraffic[i];
> >
> > dumpDomains bails only if the name hasn't yet been resolved:
> >
> > // if we didn't get a domain name, bail out
> > if ((el->fullDomainName == NULL)
> >
> > || (el->fullDomainName[0] == '\0')
> > || (el->dotDomainName == NULL)
> > || (el->hostResolvedName[0] == '\0')
> > || broadcastHost(el)
> >
> > ) {
> > continue;
> > }
> >
> > vs. a bunch of tests in dumpHosts, including:
> >
> > if(el->hostNumIpAddress[0] != '\0') {
> > ...
> > } else {
> > /* For the time being do not save IP-less hosts */
> > el = el->next;
> > ...
> > continue;
> > }
> >
> > However, like hostResolvedAddress, hostNumIpAddress should get valued
> > during the ntop run, perhaps not immediately, but certainly within
> > secods/minutes - so that we might miss a few cycles, but that's not the
> > 10x difference on every cycle you're seeing.
> >
> > If anything, I would expect the dumpDomains value to be right and the
> > dumpHosts wrong.
> >
> > See here's what's weird. For me, the data points that are in common
> > match:
> >
> > # rrdtool fetch eth0/domains/burtonstrauss.com/bytesRcvd.rrd AVERAGE |
> > grep -v nan | grep -v '0\.0000000000e+00'
> > counter
> >
> > 1077951900: 1.1114381271e+03
> > 1077952200: 4.1864169454e+02
> >
> > # rrdtool fetch eth0/hosts/217/160/226/66/bytesRcvd.rrd AVERAGE | grep -v
> > nan
> > counter
> >
> > 1077951900: 1.1114381271e+03
> >
> >
> > If I'm reading things correctly, Bill is using a single interface and
> > capturing packets, Markus is using netFlow.
> >
> > Bill, are you sure that the domain stats are wrong and the hosts stats
> > right? The different loop is the one thing that would explain BOTH
> > issues (plus what I'm seeing on my system). But then the 20GB domain
> > would be right and the lower host value wrong...
> >
> >
> > -----Burton
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> > > Of Markus Rehbach
> > > Sent: Saturday, February 28, 2004 2:32 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: [Ntop-dev] values in upToXYZPkts RRD graphs are too low (about
> > > factor 10)
> > >
> > >
> > > Hi all,
> > >
> > > comparing the ethernetPkts RRD graph with the sum of the upToXYZPkts is
> > > showing a difference by about factor 10.
> > >
> > > The graphs for eth0 seems to be correct.
> > >
> > > It is clear that differences must exist between 'raw packets' and
> > > NetFlow because of the quanifying effects of NetFlow (concerning the
> > > packet sizes lower values in the biggest and smallest sizes), but I'm
> > > exporting the NetFlow stuff every 5 seconds and therefore the
> > > differences sould not be big.
> > >
> > > What do you think?
> > >
> > > Markus
> > >
> > > _______________________________________________
> > > Ntop-dev mailing list
> > > [EMAIL PROTECTED]
> > > http://listgateway.unipi.it/mailman/listinfo/ntop-dev
> >
> > _______________________________________________
> > Ntop-dev mailing list
> > [EMAIL PROTECTED]
> > http://listgateway.unipi.it/mailman/listinfo/ntop-dev
>
> _______________________________________________
> Ntop-dev mailing list
> [EMAIL PROTECTED]
> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
_______________________________________________
Ntop-dev mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
