I think the calc is spurious... that is it's doing percentages on the
partial total. The problem is that much like we can't say across the OSes
what that counter is, we can't say whether the dropped count is or is not
part of the libpcap reported totals...
in pcap.h all you see is the structure:
/*
* As returned by the pcap_stats()
*/
struct pcap_stat {
u_int ps_recv; /* number of packets received */
u_int ps_drop; /* number of packets dropped */
u_int ps_ifdrop; /* drops by interface XXX not yet supported
*/
};
and in man pcap, a too-brief description:
int pcap_stats() returns 0 and fills in a pcap_stat struct. The
values
represent packet statistics from the start of the run to the time
of
the call. If there is an error or the under lying packet
capture
doesn't support packet statistics, -1 is returned and the error
text
can be obtained with pcap_perror() or pcap_geterr().
If you do a google search (say ps_drop libpcap -ntop), you'll find some
interesting discussions, e.g.
http://www.tcpdump.org/lists/workers/2001/07/msg00019.html
http://www.mcabee.org/lists/snort-users/Dec-01/msg00593.html
and esp.
http://www.mcabee.org/lists/snort-users/Jan-02/msg00771.html
"...In particular, here is the
skinny on how libpcap manages the "pcap_stat" structure:
filter
OS applied ps_recv ps_drop
linux before all packets that passed packets that passed the filter
the filter including but dropped due to lack of buffer
those that were dropped. space.
bsd after ALL packets that hit (Same as linux)
the network interface
before being filtered
including packets that
passed the filter and
packets that were dropped."
So I think you can see how code that's correct under one system is wrong on
the other.
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David
Touitou
Sent: Monday, October 20, 2003 4:02 PM
To: [EMAIL PROTECTED]
Subject: Re: [Ntop] Dropped by the kernel
Burton M. Strauss III wrote:
> Get a faster NIC/Processor.
P3-733 (133 MHz FSB) and Intel 82559 Pro/100 Ethernet (with microcode
loaded, aka less interrupt calls)) are not fast enough for 9Mbps
bandwidth stats ?
Wow...
What kind of hardware should be used here ?
> You're going to have to do some research to figure out what that counter
> means on your OS.
I'll do that tomorrow.
> So it might be ntop not accepting packets fast enough, or it might be a
true
> drop in the kernel before ntop ever sees them - typically, the kernel
drops
> packets when it can't keep up with the interrupt rate (either the NIC
buffer
> being overflowed or the kernel buffer).
What I don't understand is that ntop states packet is dropped BUT
counted in traffic stats, protocol stats, etc.
And that I got more packets dropped than packet actually counted
(percentage over 100%). How can this happen ?!
After a few hours (5:40), I'm now down to 73% packet dropped, while the
bandwidth is still arround 9Mbps with more packets than ever (people
playing on game servers for arround 2Mbps).
David.
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop
