Zeroth, you might try a version of ntop that's not an old beta.  Don't
expect anything different, but I ain't supporting 2.0.anything...

First off, you need to treat the pcap reported drops with a grain of salt.
See this thread, for example
http://www.tcpdump.org/lists/workers/2001/07/msg00018.html and this msg
http://www.mcabee.org/lists/snort-users/Jan-02/msg00771.html  There's a lot
of other stuff, esp. snort - STFW for "libpcap ps_drop".

Second, what's the card that's giving you trouble... research that one.  But
a lot of the cheapos just don't have the buffering and cpu offload of a
3c905c or such.  You can use ifconfig and should be able to see if the drops
are at the NIC (maybe a bad nic) or really in the kernel.

Third, WRT GigE, remember that you can suck a lot more traffic over that
network than an old PC can handle (i.e. the bandwidth limitations of 32bit
PCI and PC100/133 RAM, heck even PC2700 DDR).  Once upon a time, I read
about "zero copy" - look here http://people.freebsd.org/~ken/zero_copy/ for
the FreeBSD stuff.  Quoting:

"What is "zero copy"?
Zero copy is a misnomer, or an accurate description, depending on how you
look at things.

In the normal case, with network I/O, buffers are copied from the user
process into the kernel on the send side, and from the kernel into the user
process on the receiving side.

That is the copy that is being eliminated in this case. The DMA or copy from
the kernel into the NIC, or from the NIC into the kernel is not the copy
that is being eliminated. In fact you can't eliminate that copy without
taking packet processing out of the kernel altogether. (i.e. the kernel has
to see the packet headers in order to determine what to do with the payload)

Memory copies from userland into the kernel are one of the largest
bottlenecks in network performance on a BSD system, so eliminating them can
greatly increase network throughput, and decrease system load when CPU or
memory bandwidth isn't the limiting factor. "

So, BEST CASE, you have to copy the data NIC->Kernel and without zero copy,
it happens TWICE.  Then, once you're in the kernel, it has to hand the data
off to libpcap (another copy) and from libpcap to ntop.  So we're moving the
data 3 or 4 times... best case!

Let's do some off the cuff math.  Looking here
http://www6.tomshardware.com/mainboard/20020501/ddr400vsrambus-05.html shows
a table of memory types and max bandwidth (picking a few):

Label  Name  Effective Clock  Data Bus Bandwidth
PC100  SDRAM       100 MHz     64 Bit  0,8 GB/s
PC133  SDRAM       133 MHz     64 Bit  1,06 GBb/s
PC2700 DDR333      166 MHz     64 Bit  2,7 GB/s

See the problem?  A fully loaded GigE link is 1 Gb/s.  4x that is 0.5 GB/s -
so if ALL that's going on is the capture of packets from the network, the
CPU can keep up.  Maybe.  Those bandwidth numbers are theoretical, best case
(nice sequential access).  Throw in some other system activity, cache misses
and CAS/RAS issues... and um...


If this were my system, I'd fix things before throwing more data at ntop.

-----Burton


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony
Hernandez
Sent: Thursday, February 20, 2003 2:18 PM
To: [EMAIL PROTECTED]
Subject: RE: [Ntop] Ntop/freeBSD kernel dropping a LOT of packets &
multi processor support


Thanks, for the input. Ill have to try that. I'm looking into getting a GB
card + these features you know if it exists or any suggestions ?

-----Original Message-----
From: Burton M. Strauss III [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 20, 2003 1:10 PM
To: [EMAIL PROTECTED]
Subject: RE: [Ntop] Ntop/freeBSD kernel dropping a LOT of packets &
multi processor support


ntop's just echoing a counter maintained by libpcap - typically from the OS.

Get a better NIC.  Seriously, for that much traffic it needs to be a real
one, with processor offload and big buffers.  Otherwise the NIC's buffers
get swamped before the CPU takes the data of the NIC.  Look into the FreeBSD
stuff, see if they've implemented a "zero copy" option - which some Linux
drivers have.

STFW ... freebsd packet drop kernel gives some interesting looking reading

-----Burton

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony
Hernandez
Sent: Thursday, February 20, 2003 10:26 AM
To: [EMAIL PROTECTED]
Subject: [Ntop] Ntop/freeBSD kernel dropping a LOT of packets & multi
processor support


Is there any tuning that can be done to the freeBSD kernel to make it
not drop so many packets? I have a dual 1.6ghz machine running freeBSD
i386-unknown-freebsd4.7 - ntop version 2.0.99. example:

Total 12,831,403
Dropped by the kernel 31,991,548

This machine is connected into our border that happens to be listening
to trafic up to our max bandwidth which is 1GB. Ntop doesn't seem to be
having much of an issue at this point seems to be mostly kernel related
to freeBSD .. Anyone seent his before ?




--
Tony Hernandez
Computer Programmer
Division of Housing
University of Florida
"All your base are belong to us!" -Zero Wing
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop

_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop

_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop

Reply via email to