Luca, ntop was tested on both machines with little traffic, on the ultra5 for example with a ssh connection and the traffic from ntop's webpage only (plus some dns and dhcp). Just by using the webpage I could force the libpcap thread to quit. The low cpu speed of this machine is only relevant to enhance the wicked behavior of ntop on FreeBSD.
Regarding FreeBSD's threading, it would be very interesting in getting some of the core developers eyes on this issue. Joao Barros On 5/6/05, Luca Deri <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Joao, > why is the CPU a problem for you? Because you have little traffic to > analyze or because you expect a lighter CPU usage? How did you configure > ntop and where (topology, network speed etc)? Bearn in mind that ntop > has been designed (default) to monitor a LAN so if you have a WAN or a > large network you better configure properly. > > FreeBSD is definitively not the best OS in terms of threading (although > many other things work nicely and probably better than other similar > OSs). I have no experience on Sun+BSD, so I cannot really provide you a > more precise answer to your problem. > > Cheers, Luca > > Joao Barros wrote: > > 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 > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (Darwin) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFCe5Z4mMhDxnkh3zQRAvVeAJ9FsrSpDar9yOrqEd1zkzxCOJI5fgCaA2CW > kAHqrFyrfIMBHqPvF23fnBo= > =Q9lg > -----END PGP SIGNATURE----- > _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
