It's probably also worth checking out a couple of things:
Thanks for positive answer and ideas 8-)
1. Turn off ntop and just use tcpdump on the interface. What kind of stats do you get? Then turn of DNS resolution for tcpdump and run it again. Same or better?
ntop is stopped, fxp1 still with microcode loaded, promiscuous mode. I'm connected to the probe using ssh on fxp0.
tcpdump with DNS resolution to screen it not OK :
probe# tcpdump -i fxp1
.../snipped data on screen/...
^C
13067 packets received by filter
10959 packets dropped by kerneltcpdump with DNS resolution to file is OK :
probe# tcpdump -i fxp1 -w tcp.dump
tcpdump: WARNING: fxp1: no IPv4 address assigned
tcpdump: listening on fxp1
^C
192737 packets received by filter
0 packets dropped by kernelLooks like there's no problem with tcpdump writing to a file. No packet lost in kernel at all, no buffer problems, etc.
I guess (I'm not a programmer at all) problem is between the libpcap (kernel) and ntop handling the data from libpcap : it does not handle the data fast enough so slows down the results and make the kernel drops packets.
Just like having tcpdump output to screen make the kernel drops packets.
ntop uses "only" 25 to 30% of CPU. interrupts is less than 5%
I guess faster CPU is still the answer ? At least, kernel/NIC is not the problem.
Is ntop able to run with several threads on a SMP system ?
2. Check to see if you're generating large numbers of small packets. I've found that even a P3-1.4GHz 512Meg RAM, has trouble keeping up with large numbers of small packets (possibly a combination of [hardware] platform, NIC, NIC drivers and the linux kernel version).
I know I'm having a lot of small udp packets (due to game servers hosting).
I'll make a try tomorrow with another fxp card chipset release.
David.
_______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
