See [BMS]'s inline -- also consider punctuation and carriage returns in the future - run-on sentences are difficult to read, esp. for non-native English speakers.
-----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, September 07, 2005 12:38 PM To: [email protected] Subject: [Ntop] My feedbacks on Ntop Hello list, This is my feedbacks on Ntop. 1) - It would be nice if we can have an option into configure to enable or disable XMLDump, by defaut if libxml2, dome, and very OLD glib1 are not available, then the XML feature is not functional, that's correct but I don't understand why "libxmldumpPlugin" and "xmldumpPlugin.so" are still compilled and installed!! Therefore having an option to enable or disable this feature could be a good addition to the source, also why you still use glib version 1.x? [BMS] Live with it. The gnu tools don't like missing .o files (they insist on recompiling each time you 'make' then you get problems from files owned by root after the make install). So it's easier to have an empty 'program'. [BMS] There's no ntop dependency on glib1. We happily run with whatever is installed on the box. Here's my Fedora Core 3 box: $ rpm -q --whatrequires glib gdome2-0.8.0-1 pam-0.77-40 gtk+-1.2.10-29.1.1 GConf-1.0.9-13.1 gnome-vfs-1.0.5-18 glib-devel-1.2.10-12.1.1 2) - Running Ntop for home user or small company using Hub work fine because they have not lot of trafics on their network and Ntop work nice on this environement but when we talk about medium or large entreprises using switches (Cisco, FoundryNetwork), then Ntop become a problem. For Ntop to work, we have to use additional switch features like Netflow for Ntop to see the trafic or SPAN if we don't have US 3000$ to buy a Netflow card. [BMS] Do the math. NO general purpose computer can keep up with backbone frame rates. There's simply not enough memory bandwidth. 10,000 9K packets per second - where each packet (at best) has to xfer from the NIC to kernel buffer, and then kernel buffer to user space - is 1.4 Gbps. Toss in real-world, where there's at least one extra copy and... Remember: PC3200 maxes out at 3.2 Gbps. Real-world throughput is less. And that's without any ntop processing. [BMS] Check the stats on the about page. On a 1 GHz P3, ntop can handle about 1-2K packets / second (regular, not jumbo). [BMS] So technologies like netFlow (1) do massive data reduction - 15 9K packets -> 1 1400 byte flow packet and (2) reduce the per-packet processing times, because we don't see the internals and so don't do deep packet inspection. [BMS] If you are running in the enterprise space, you have to expect to spend $s for enterprise hardware. Or do you think a hardware sniffer is free? In both way activating Netflow or SPAN will generate lot of trafics on the server (also on the switch for SPAN) where Ntop is running and even with an Intel Pro 1000 Ethernet Adapters supporting Jumbo Frame, NAPI, etc, the server and Ntop are not able to handle the load. Ntop consume 80% of all CPU resources and all 3GB of RAM + 1GB of swap in a minute. [BMS] Re traffic, yes. Any monitoring technology will have overhead. [BMS] With Span it's the 100 or 1000 Mbps of the link itself. With netFlow it's the flow packets. If you are so tight on bandwidth that you can't handle this, then set up a private link (a/k/a a wire) to keep the traffic off the backbone. [BMS] Re memory usage, we've cut it way down, but the hard facts are that there is some overhead for EVERY host we monitor. Source and destination. Or you can use filters and switches to cut it down to what you need to monitor. Like everything in life, you have to live within your means. [BMS] FWIW, under Linux, ntop shouldn't use that much CPU. Under FreeBSD it's an artificial usage because of the userland threads as explained in the FAQ. Since the kernel still need to manage other process, it will automaticaly kill the process causing the problem by consuming all resources (yes Ntop). [BMS] ntop should - especially in a production environment - run on a standalone box. So which server should I have to run it? A 4 Xeon processors hypertheading with 50GB of RAM on a RAID SCSI system? Ok there is a PF_RING solution that ONLY work with old libpcap version and old Linux Kernel with old GCC version too, so when you use a new Linux system to be update and bug fix, you cannot use this solution and even applying this solution with old software version doesn't fix the above problem. [BMS] Above 1 core per NIC (or maybe 2 + #NICs), ntop won't see any benefits. The packet processing threads could max out a core per NIC, and the web server one, with the rest lightly loading another core. But ntop runs OK even on a single processor with modest loads. [BMS] So take it up with the network device driver authors - why are their drivers so slow? All we can do is to use what's available to us. PF_RING was a research project to see if significant improvements COULD be made. If it's so important to you to keep it current, and you are in an enterprise environment, then consider funding the development effort. Yes ntop is a great software and I like it, but I'm affraid to explain all of the above in the entreprise when I've to deploy it. [BMS] So don't. You have choices - spend $50K + hardware costs and license a commercial product or spend less for the admittedly lower functionality of ntop. Or, take some of that money and fund development projects to improve ntop to meet your needs, which benefit everyone... The benefit of ntop is not that it's the only solution for everyone, it's that you have the choice! Gerhard, _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
