Thanks. I was able to get money allocated for a few new machines specifically for ntop - server-class boxes with some nice hardware. I'll sit tight until they arrive. Thank's for the explanation/suggestions.
-Chris -----Original Message----- From: Burton M. Strauss III [mailto:[EMAIL PROTECTED] Sent: Thursday, April 08, 2004 10:04 PM To: [EMAIL PROTECTED] Subject: RE: [Ntop] dropped packets 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 _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
