Messages in this thread |  | | | Subject | Re: Flood ping | | Date | Fri, 25 Sep 1998 17:20:15 +0300 (EEST) | | From | Matti Aarnio <> |
| |
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/
|  |