Um... sorry, I was thinking you were talking about the netflow packet timeout (missed the asymetric nature of your connection)...
CPU 100% could be a symptom of two bugs we've found - one in the dns resolution thread and another in the netflow (sflow?) setup if the listening socket is zero. Both are fixed in the latest CVS, but there is a big problem in there with daemonizing that renders ntop unusable (after the 04Apr2002 snapshot). I think I just tagged the daemonizing bug - I'm testing right now on another session, so... give me a few minutes and (if I'm right) I will post the patch that would let you use the versions w/o the cpu usage bug... (e.g. latest CVS)... that way you'll really see what your CPU usage is... The things to look for are: 1) ntop should not be using swap space - if you don't have enough memory to keep the structures in memory, then reporting (which walks the structures) will be very painful and 2) < 100% CPU usage -----Burton -----Original Message----- From: Christian Hammers [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 9:30 AM To: Burton M. Strauss III Cc: [EMAIL PROTECTED] Subject: Re: [Ntop-dev] still have missing data in netflow export On Thu, Apr 11, 2002 at 09:20:55AM -0500, Burton M. Strauss III wrote: > That said, a big enough box should be able to handle 3x100 Mbps, but be > aware that with three SATURATED links you're getting close to the memory > bandwidth of many Intel Pentium III computers. (But my memory is fuzzy about > the details here). How will I notice that? I guess at least the CPU will be busy handling that amount of data and the interrupts per seconds number will raise very high, too, so I am far away right now: procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 1 0 5588 11852 74068 0 0 0 45 218 119 1 1 98 0 0 0 0 5588 11852 74068 0 0 0 4 283 117 0 5 95 bye, -christian- P.S.: The timeout thing I was looking for is in session.c's scanTimeoutedTCPSessions(), esp. the following thing, as I have only "lost packets" in asymetric routing: if(((thisSession->sessionState == STATE_TIMEOUT) && ((thisSession->lastSeen+TWO_MSL_TIMEOUT) < myGlobals.actTime)) || /* The branch below allows to flush sessions which have not been terminated properly (we've received just one FIN (not two). It might be that we've lost some packets (hopefully not). */ -- Christian Hammers WESTEND GmbH - Aachen und Dueren Tel 0241/701333-0 [EMAIL PROTECTED] Internet & Security for Professionals Fax 0241/911879 WESTEND ist CISCO Systems Partner - Authorized Reseller _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listmanager.unipi.it/mailman/listinfo/ntop-dev
