[lkml]   [1998]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Flood ping
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 <>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:44    [W:0.274 / U:1.384 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site