Date: Fri, 17 Nov 2000 09:19:23 -0800 (PST) From: Mikko Tyolajarvi <mikko@dynas.se> To: Stanley.Hopcroft@IPAustralia.Gov.AU Cc: freebsd-questions@freebsd.org, billf@freebsd.org Subject: Re: ntop, worlds greatest network monitor, no go on FreeBSD Message-ID: <200011171719.eAHHJNB18389@explorer.rsa.com> References: <Pine.BSF.4.21.0011161441220.921-100000@stan.aipo.gov.au>
next in thread | previous in thread | raw e-mail | index | archive | help
(Cc-ing maintainer of "ntop" port) In local.freebsd-questions you write: >I am writing to ask for someone to provide advice to the ntop project >(http://www.ntop.org) on porting to FreeBSD. >There are a number of problems with ntop (1.3.2 26th October) on >FreeBSD (eg Mr Petri's letter of a few weeks ago) among them that when >it's built with pthread support (-pthread), it uses all of the CPU >(built without pthread support, it behaves). [...] >There is a port of ntop (for 1.1) but it displays the same CPU hogging >behaviour as the later version. Well, what do you know... I've always thought "ntop" was neat, but used too much resources to be of any practical use, but building it without threads makes it far more useful :-) Ok, I had a quick look at what is going on, and came up with: - truss ntop -> it is spending almost all of its time reading from a "bpf" device, which keeps returning zero immediately. - The threads library makes all file descriptors non-blocking in order to be able to multiplex between them. - As far as I can tell (/sys/net/bpf.c), bpf will return zero when in non-blocking mode, if there is no data. But the threads lib expects -1, with errno == EWOULDBLOCK, and so does not block the thread, which then immediately calls read() again. - And there is your loop... I don't know if bpf is at fault, or if libc_r needs to be able to work around this behaviour of bpf, but it sure doesn't work too well. This is tested with the ntop-1.1 port on 4.2-BETA (built from -STABLE yesterday), so I don't think any of the latest pthread fixes will help. (I tried building the latest snapshot of ntop, but gave up when it started bitching about "wrong version of gdbm" and being genereally very unco-operative and linux-like. I assume it will go on and require the latest snapshot of every library beginning with a "g"...) Have you filed a PR? $.02, /Mikko P.S. Meanwhile, this makes the "ntop" port usable: vaio# diff -u Makefile.org Makefile --- Makefile.org Fri Nov 17 09:06:57 2000 +++ Makefile Fri Nov 17 09:07:43 2000 @@ -16,6 +16,7 @@ MAINTAINER= billf@FreeBSD.org HAS_CONFIGURE= yes +CONFIGURE_ARGS= --enable-threads=no ALL_TARGET= INSTALL_TARGET= install install-man -- Mikko Työläjärvi_______________________________________mikko@rsasecurity.com RSA Security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011171719.eAHHJNB18389>