Re: Flood ping

Matti Aarnio (matti.aarnio@sonera.fi)
Fri, 25 Sep 1998 17:20:15 +0300 (EEST)


Alan Cox spoke thusly:
> Jauder Ho wrote:
> >
> > actually /proc/net/dev is broken for byte count if anyone cares to fix it.
> >
> > face |bytes packets errs
> > eth0: 0 30156456 0
>
> Not all devices currently support byte counts is the probable cause

Or rather, not all devices add to rx_bytes field of the
'ethernet stats' structure. While Tulip does, 3c59x does not.

Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed
eth0:34684084 178447 0 0 0 0 0 0 332627 71867 0 0 0 71867 0
eth1: 0 308856467 2 0 0 2 0 0 0 308847138 0 0 0 11857 0 0

Lets see..
RX packets:309569510 errors:2 dropped:0 overruns:0 frame:2
TX packets:309560182 errors:0 dropped:0 overruns:0 carrier:0
which with 1480 byte packets would mean something like 350 GB,
and with 148 byte packets it would mean "mere" 35 GB. The
thruth is somewhere in between. (Full-frame ping rate is about
5 MB/sec, while small-frame load is about 0.8 MB/sec. Yeah,
the NET_BH sucks..)

And also, those counters being 'long', full-frame pings on this
type of links will overflow 32-bit values in less than 15 minutes.
I recall there has been "some" opposition at using 'long long'
(64-bit) type variables at the counters.

This is an Alpha machine using my edition of 3c59x 0.99F driver,
and it is getting flood-ping via dedicated point-to-point 100BaseTx
full-duplex cable from my PPro200 Linux box. Currently the interrupt
load spins around 11000 interrupts per second on that card...

/Matti Aarnio <matti.aarnio@sonera.fi>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/