(Well, you're assuming I remember anything about you or your situation - bad
idea unless you are one of the few paying for support).
With the malloc() chains problem fixed, ntop is finally staying up for more
than 5m for me. Here's some interesting data...
(eth1)
Received (libpcap) 2,148,961
Less: Dropped (libpcap) 0
Gives: Given to ntop 2,148,961
Total Received by ntop 2,148,961
Dropped by ntop 0.0% 87
Total packets processed 2,148,875
Unicast 97.9% 2,102,727
Broadcast 2.1% 45,281
Multicast 0.0% 867
(eth2)
Received (libpcap) 8,171,002
Less: Dropped (libpcap) 0
Gives: Given to ntop 8,171,002
Total Received by ntop 8,171,002
Dropped by ntop 0.0% 46
Total packets processed 8,170,955
Unicast 13.4% 1,096,411
Broadcast 86.6% 7,074,544
Multicast 0.0% 0
With the fixes in the code, that 'Dropped by ntop' comes from one and only
one place... pbuf.c:
/*
If we reach this point it means that somebody was already processing
a packet so we need to queue it
*/
if(myGlobals.packetQueueLen >= CONST_PACKET_QUEUE_LENGTH) {
myGlobals.receivedPacketsLostQ++;
incrementTrafficCounter(&myGlobals.device[getActualInterface(deviceId)].drop
pedPkts, 1);
Which means a burst large enough to overwhelm the queue (*probably when the
mutexes were locked during a big purge*). Sure enough (87+46 = 113), from
info.html:
Packets
Received 10339702
Processed immediately 9529989
Queued 810013
Lost in ntop queue 133
Current queue 0
Maximum queue 2049
Now Tigger is a dual P3-1000, with
eth1 Link encap:Ethernet HWaddr 00:03:47:B1:62:27
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:47444109 errors:0 dropped:0 overruns:0 frame:3453241
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:3674881566 (3504.6 Mb) TX bytes:0 (0.0 b)
Interrupt:9 Base address:0x1000
eth2 Link encap:Ethernet HWaddr 00:60:97:04:30:33
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:140191757 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:410437865 (391.4 Mb) TX bytes:0 (0.0 b)
Interrupt:9 Base address:0xb800
eth1 is an Intel Dual Ethernet Pro/100
eth2 is a 3c905 (B or C, I don't remember)
So they're decent cards, having no problems keeping up with the LAN or a
1.5Mbps CableModem. And that shows in the ifconfig stats.
Let's check your host (OK, so I checked my history file and found the
pointer to your ntop instance)...
Packets
Received 20071188
Processed immediately 20071188
Queued 0
Current queue 0
Maximum queue 0
Received (libpcap) 21,157,814
Less: Dropped (libpcap) 934,767
Gives: Given to ntop 20,223,047
Total Received by ntop 20,222,858
Gives: Total packets 20,222,858
Unicast 99.9% 20,192,780
Broadcast 0.1% 24,871
Multicast 0.0% 5,207
So we're back to the same old ugly question. WHY IS FREEBSD LIBPCAP
DROPPING (MORE THAN A TRIVIAL # OF) PACKETS.... 4.4% or so...
There's this note:
http://www.tcpdump.org/lists/workers/2002/12/msg00097.html
which was never answered but seems to blame the tools. That's back to my
hypothesis that they're simply not taking packets fast enough from the
libpcap buffers.
Remember, ps_drop comes from the OS - that's this code from pcap-bpf.c:
int
pcap_stats(pcap_t *p, struct pcap_stat *ps)
{
struct bpf_stat s;
/*
* "ps_recv" counts packets handed to the filter, not packets
* that passed the filter. This includes packets later dropped
* because we ran out of buffer space.
*
* "ps_drop" counts packets dropped inside the BPF device
* because we ran out of buffer space. It doesn't count
* packets dropped by the interface driver. It counts
* only packets that passed the filter.
*
* Both statistics include packets not yet read from the kernel
* by libpcap, and thus not yet seen by the application.
*/
if (ioctl(p->fd, BIOCGSTATS, (caddr_t)&s) < 0) {
snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "BIOCGSTATS: %s",
pcap_strerror(errno));
return (-1);
}
ps->ps_recv = s.bs_recv;
ps->ps_drop = s.bs_drop;
return (0);
}
Since those stats appear to come from the NIC driver, I think you're going
to have to look into the fxp.c driver and figure out what it's counting in
the data it returns to BIOCGSTATS.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/fxp/
-----Burton
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David
Touitou
Sent: Friday, November 07, 2003 9:13 AM
To: [EMAIL PROTECTED]
Subject: Re: [Ntop] Dropped by the kernel
Hi all,
Burton M. Strauss III wrote:
> Let us know what you find out re the 82550...
The probe computer is now using it as probe.
Same ntop as two weeks ago (not recompiled yet).
Drop percentage (calculated manualy from the "new" web interface) is
about 4-5% now.
Same metrics as before for the CPU usage (20-30% global CPU usage with
arround 6% and 7-9% interrupt) with device_polling and hz=1000.
The very strange thing is that I'm currently building world on this
server (that's not that strange) and that drop percentage stays the same
whereas the CPU is now 0% idle (85% user)...
This would mean packet are not lost because of CPU usage.
I'll try to find an Athlon 2400XP (with 266FSB) or a P4 (400FSB) to
check if things are differents.
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
