On Fri, Dec 14, 2001 at 10:40:13PM -0000, James Stevenson wrote:
> Hi
>
> > > eth0 Link encap:Ethernet HWaddr 00:04:E2:1E:FE:B3
> > > inet addr:192.168.1.1 Bcast:255.255.255.0 Mask:255.255.255.0
> > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> > > RX packets:1560157 errors:559 dropped:0 overruns:559 frame:559
> > > TX packets:1855259 errors:0 dropped:0 overruns:0 carrier:0
> > > collisions:0 txqueuelen:100
> > > RX bytes:915402439 (872.9 Mb) TX bytes:1856391958 (1770.3 Mb)
> > > Interrupt:10 Base address:0xe400
>
> 2.4.16
> 100Mbps Switched
>
> PCI: Found IRQ 10 for device 00:09.0
> eth0: ADMtek Comet rev 17 at 0xe400, 00:04:E2:1E:FE:B3, IRQ 10.
> using the tulip drivers.
That is roughly 1 error for every 3000 received frames.
With 'netstat -s' you will possibly see incoming packets
being dropped:
Ip:
317338 total packets received
0 forwarded
19 incoming packets discarded
220834 incoming packets delivered
Another metric to look at is softnet_stat, these are per CPU (my
sample box for this is a dual-CPU machine), and the fields counting
frames are in order: total, dropped, time_squeeze, throttled,
fastroute_hit, fastroute_success, fastroute_defer, fastroute_deferred_out,
cpu_collisions.
# cat /proc/net/softnet_stat
0000b7c0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0000bea7 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
If you see the 'dropped' (second) field being non-zero, your system
just can't hand all packets coming in up from the device driver.
Where the overrun stems from is usually:
PCI bus master unable to get time for writing data out of
internal FIFOs before incoming data overflows those FIFOs.
(Underrun is unability to feed data into transmit-FIFOs
fast enough for packet transmission.)
All in all, if your system has many busmasters (TV frame-grabbber,
busy IDE/SCSI controllers, many network cards), it might do well
to force lower latency values for them all (at BIOS setup.)
Some chips are able to buffer things better than others, and
tolerate longer latencies, or even are able to halt the incoming
flow.
Modern network switches implement special ethernet frame reception
which says that "XOFF the incoming flow until I XON it". Lattest
Ethernet chips can be configured to send that special message
when they notice that RX buffers are becoming full.
Jeff is likely to know if this particular version of Tulip can
do that kind of flow control.
> >From /proc/pci
> Ethernet controller: Accton Technology Corporation EN-1216 Ethernet Adapter (rev 17).
> IRQ 10.
> Master Capable. Latency=64. Min Gnt=255.Max Lat=255.
> I/O at 0xe400 [0xe4ff].
> Non-prefetchable 32 bit memory at 0xea400000 [0xea4003ff].
>
> James
/Matti Aarnio
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
