See in-line -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Chris > Beck > Sent: Thursday, April 08, 2004 6:57 PM > To: [EMAIL PROTECTED] > Subject: RE: [Ntop] dropped packets > > > I'm not finding a textinfo.html on the system that I'm using ntop on. Is > that the actual name of the file?
The pointer on the bottom of info.html (About | Configuration) to a longer version of this page suitable for a problem report or some such wording. > I don't know where else to look to see what, if anything, is getting > dropped. Our NMS reports that the links being monitored are > averaging around > 976kbps since I restarted ntop this morning. But, ntop is only > reporting an > average of 38kbps. So there's a lot being dropped, I just don't > know how to > track down where it's being dropped. This is what I'm seeing on Summary -> > Traffic. > > Dropped (libpcap) 59.5% 70,569 > Dropped (ntop) 0.0% 0 > Total Received (ntop) 118,545 > Total Packets Processed 118,545 > Unicast 99.9% 118,469 > Broadcast 0.1% 76 > Multicast 0.0% 0 Well, I think there's your answer - beyond whatever is being dropped in the driver due to overruns, it's also dropping packets in libpcap. Now as to WHAT libpcap means by dropped, you are in for some digging in the code for the specific driver source. But it probably means libpcap's buffers are overflowing - often this is because ntop isn't taking the packets fast enough. Again, a sign of inadequate hardware. > The good news is, I do have a new machine on order for this, so if this is > hardware related, that should soon be eliminated. I'll look back > through the > threads for info on machine recommendations. Thanks. Anything modern will do - lose the PC100 cr*p. On high usage links, get a real NIC - 3C905 or Intel Pro/100 are one's I've had good results with. > > -Chris > > -----Original Message----- > From: Burton M. Strauss III [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 08, 2004 1:58 PM > To: [EMAIL PROTECTED] > Subject: RE: [Ntop] dropped packets > > Yes and yes. And no and no. It all depends... > > As I say in the faq entries, packets get dropped a lot of places. And > libpcap under Linux isn't very honest about it's reporting. > > Stuff reported at the driver level would be in the ifconfig counts, that's > probably (but not always) before libpcap sees them. How each particular > driver is coded and what it's reporting is, well, up to the driver writer. > Some NICs have counters that the driver can interrogate, others > don't. etc. > > Overruns are usually a network card problem on the local LAN > segment - it's > sending garbage that 'happens' to be more than the garbage counter at the > 'start' of the packet. Sort of like looking at the progression of digits > from a PRNG and thinking you see a phone number in there > 972555121212 - hey, > that's directory assistance, but there's an extra 12 in it... > But it could > be other things, it's dependent upon the NIC and driver as to > what count(s) > they are actually putting in that bucket. > > Then you have the kernel and finally libpcap. > > Now, for whatever libpcap sees, when you look at the textinfo.html stuff, > there should be a trail of where ntop thinks the packets get dropped. As > you seeing non-zero #s there? Or is it just in the dropped by libpcap > count? > > > Luca made a change late in the 3.0 development cycle to > essentially poll the > libpcap counter and store the count off in ntop's myGlobals structure so > we're less dependent upon libpcap. How much better that really is, is > still up for grabs. > > > As to too low end, I think yes. There was a back traffic message where I > did some envelope calculations about memory bandwidth - with PC100, I seem > to recall finding it was pretty easy to swamp. Might search @ Gmane for > PC100 PC133. > > -----Burton > <snip /> _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
