Hi Burton,
Thanks for your reply. Actually, I have already gone
through what you have attached to your email from the
FAQ.
> A. Long Answer: There are four places packets drop
> "in" ntop. One in
> the NIC, one in the OS kernel, one in the libpcap
> library and one
> actually in ntop.
I guess in my case, the packets do not drop in the
NIC, because ifconfig reports no packet dropped; the
packets do not drop in the OS kernel, because CPU
usage is not high according to top; the packets do not
drop in the ntop according to the traffic report from
ntop.
So, the packets are dropping in libpcap. I want to
know why that happens? Anything that I can do to
improve it? Also, what I don't understand is how come
the %dropped (libpcap) keeps on increasing?
Thanks,
Simon
--- Burton Strauss <[EMAIL PROTECTED]> wrote:
> >From docs/FAQ (because we *believe* it's much
> better in 3.2, this has been
> moved to docs/FAQarchive, which is where this copy
> is from).
> -----Burton
>
>
----------------------------------------------------------------------------
> ----
> ----- Dropped packets
>
----------------------------------------------------------
>
----------------------------------------------------------------------------
> ----
>
>
> A. Short Answer: You need a faster processor.
> Maybe.
> A. Long Answer: There are four places packets drop
> "in" ntop. One in
> the NIC, one in the OS kernel, one in the libpcap
> library and one
> actually in ntop.
>
> First off, this is largely NOT controlled by
> ntop. It's inside the
> network
> card, the network card driver and libpcap. All
> ntop does is use the
> stats
> provided by libpcap, pcap_stats:
>
> "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()."
>
> to get the value and reports it in report.con the
> Stats | Traffic
> page, some in the configuration report
> (info.html) and also on
> the problem report skeleton.
>
> The information on the Stats | Traffic page is
> simply the best available.
> However, this data is not always easy to obtain
> nor interpret.
>
> It looks great, but the reality is that the stats
> provided by libpcap
> aren't very good!
>
>
> Q. Not good? Why...
> A. The network card (NIC) reads packets from the
> wire into a small buffer.
> That buffer is emptied by the OS into it's own
> buffers which are then
> passed to libpcap. libpcap filters the packets
> (if requested) and
> passes the packets to ntop.
>
> Packets may be dropped at any or all of these
> stages, even on a system
> that does not appear to be exceptionally busy.
>
> Q. How can packets be lost in the NIC?
> A. A NIC has a small buffer - modern cards have 8K,
> 12K, even more buffer
> space. But if traffic comes in off the wire
> faster than the processes
> are pulling it out of the NIC, well that buffer
> gets over-written and
> packets get dropped.
>
> Every time a packet comes in (or on some newer
> cards after a few packets
> are recevied), the NIC interrupts the processor
> (CPU) to tell it to do
> something. This isn't a problem - some NICs with
> larger buffers
> internally queuing a number of packets before
> interrupting the OS to
> boost performance.
>
> Check ifconfig for this:
>
> eth0 Link encap:Ethernet HWaddr
> 00:D0:09:77:85:B9
> inet addr:192.168.42.6
> Bcast:192.168.42.255
> Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST
> MTU:1500 Metric:1
> RX packets:3892397 errors:30
> dropped:0 overruns:0 frame:33
>
> ^^^^^^^^^
> TX packets:473009 errors:0 dropped:0
> overruns:0 carrier:0
> ^^^^^^^^^
> collisions:1073 txqueuelen:100
> RX bytes:2606704447 (2485.9 Mb) TX
> bytes:70474880 (67.2 Mb)
> Interrupt:11 Base address:0xc000
>
> Now, if it's an occasional burst, losing 1 or 2
> packets won't kill
> you. TCP/IP recovers. And ntop's statistics
> aren't life-critical.
> If, however, it's continuous, on-going and the
> count is growing - i.e.
> the NIC/CPU combo can't keep up with the AVERAGE
> network flow?
>
> You're toast...
>
> Upgrade the Processor or NIC. Maybe.
>
> Q. Can you tell if the NIC is the bottleneck?
> A. Probably not. Different NIC cards (and NIC card
> drivers) record
> different
> information. Different tools present pieces and
> parts of it differently.
>
> For example, a runt packet - one that is too
> short to really be a packet
> is supposed to be discarded according to the
> tcp/ip standard. But do you
> count it as a packet received??
>
> On many systems, interface level (NIC) statistics
> are available through
> the ifconfig (or similar) command. But what is
> available and what they
> mean can be different - even though they're
> presented in the same format.
> Different programs can read the 'same' data and
> show different things.
>
> For example - eth1 is an Intel Ethernet Pro/100,
> eth2 a 3c905...
>
> # netstat -i --all
> Kernel Interface table
> Iface MTU Met RX-OK RX-ERR RX-DRP
> RX-OVR TX-OK TX-ERR TX-DRP
> TX-OVR Flg
> eth1 1500 0 50752227 0 0
> 0 0 0 0
> 0 BMPRU
> eth2 1500 0 145053154 0 0
> 0 0 0 0
> 0 BMPRU
>
> No errors - great, right? But look at ifconfig,
> a few seconds earlier:
>
> # ifconfig
> eth1 Link encap:Ethernet HWaddr
> 00:03:47:B1:62:27
> UP BROADCAST RUNNING PROMISC MULTICAST
> MTU:1500 Metric:1
> RX packets:50754251 errors:0 dropped:0
> overruns:0 frame:3454146
> TX packets:0 errors:0 dropped:0
> overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:667103055 (636.1 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:145056087 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:1784472399 (1701.8 Mb) TX
> bytes:0 (0.0 b)
> Interrupt:9 Base address:0xb800
>
> If I'm reading the code right, then the
> frame:nnnn count is set here:
>
> sp->stats.rx_frame_errors +=
> le32_to_cpu(sp->lstats->rx_align_errs);
>
> Meaning? No clue - the writer of the driver had
> to sign an NDA and so
> couldn't explain a lot of what the driver does.
> Besides, that data
>
=== message truncated ===
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
_______________________________________________
Ntop mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop
