As I've said earlier this week, you are probably NEVER going to 'fix' the cpu usage. It's simply the way things are.
In systems with kernel threads, the libpcap libraries use blocking calls to wait for the next packet. This connects indirectly to the interrupts from the network card. So while waiting for packets there is no CPU usage. Example: Linux... On systems with userland threads (e.g. FreeBSD), things get trickier - it all comes down to the implementation of the bpf pseudo-device and how it handles waiting for packets. Empirically, the 4.x series converted the libpcap calls to poll() calls - hence the 100% CPU. Some of this was fixed in the 5.x series - but I don't know what's up with the new release (it's not officially out yet). Maybe somebody else want's to pick up the technical details of supporting FreeBSD? Somebody with enough equipment to be able to track two versions plus various RCs etc.? All I do is make sure it compiles and runs in a Virtual Machine... The piece you want to look at is (probably) bpfread() (esp. the sleeping stuff) in http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/bpf.c and how it's changed over the years and what the underlying sleep functions do in various FreeBSD releases ... But at that point you are way beyond where I care to go... -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joao Barros Sent: Friday, May 06, 2005 8:29 AM To: [email protected] Subject: [Ntop] ntop on FreeBSD 5.4ish and threading Hi all, 1st post :) I installed ntop from ports on my Sun Ultra5 400MHz running FreeBSD 5.4RC3 and noticed the cpu would go to 100% and stay there (98% ntop process and load average 1.0). I could see traffic being analised throught the webpage but poking around the page would caus e this to happen: ntop[86069]: THREADMGMT: pcapDispatch thread terminated... and of course, no more captured packets which ntop would report correctly on the number of discarded packets by libpcap. I already read about this in the mailing list archives but tried to reproduce it on my laptop, a P4m 2.0GHz running FreeBSD 5.4RC4. Since this cpu is somewhat faster I couldn't get the pcapDispatch thread to terminate, but still got some packets discarded by libpcap and yet 100% cpu usage, but this time still with load average at almost 1.0 but the ntop process low although I see it's pushing for the kernel. top after about 5mins after starting ntop: last pid: 61804; load averages: 0.95, 0.54, 0.60 up 0+03:27:52 06:40:50 30 processes: 2 running, 28 sleeping CPU states: 12.0% user, 0.0% nice, 80.2% system, 7.8% interrupt, 0.0% idle Mem: 47M Active, 111M Inact, 40M Wired, 68K Cache, 34M Buf, 40M Free Swap: 400M Total, 400M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 61801 nobody 123 0 47304K 33040K RUN 2:36 39.07% 39.06% ntop Notice the 80% used by system. I tried ntop 3.1 from ports on both systems and 3.1.1 from cvs today on the laptop, both with the same results. quoting Burton: "However, I'm not all that comfortable changing the basic daemonizing logic w/o a lot of testing - that's why we held off - it was too close to 3.0's release on that change. Maybe it is time to try this - but only if we can get people to commit to trying the cvs. The results from the last few requests for help testing has been resounding silence." I'm willing to test anything you through at me, so please do :) My thanks in advance, Joao Barros _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
