Date: Wed, 25 Mar 1998 06:21:43 -0500 (EST) From: black@bleep.ishiboo.com To: freebsd-hackers@FreeBSD.ORG Subject: interface byte count insanity Message-ID: <19980325112144.20157.qmail@bleep.ishiboo.com>
next in thread | raw e-mail | index | archive | help
i've been mucking around with struct if_data to get useful interface
statistics out of the kernel and have stumbled upon some rather ugly
behavior.
theo deraadt wrote a little kernel patch for me that adds a socket
ioctl call to return the if_data structure for an interface, and i
then modified ifconfig to print interface stats using the new ioctl.
i tested on a P6-200 running vanilla 2.2.5R using de, fxp, and vx
cards.
for all cards tested the byte counts for both input and output are
complete, though slowly increasing, garbage. after transferring over
100MB through the interface i saw this:
de0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
82632 packets input, 39371 bytes, 0 drops, 0 errors
39371 packets output, 2178386 bytes, 154 collisions, 0 errors
inet 172.21.8.239 netmask 0xffffff00 broadcast 172.21.8.255
ether 00:40:05:41:10:18
media: autoselect (10baseT/UTP) status: active
the packet counts are about right, but the byte counts are obviously
silly.
another oddity is the higher collision rate with the de card vs. the
fxp card. i saw single digit collisions for the same amount of data
with the fxp. i will re-run the tests to verify this behavior.
do any of the current ethernet drivers correctly increment their byte
counts? would anyone be averse to expanding struct if_data to include
more detailed stats on errors and collision types? would the kernel
and ifconfig patches be worth commiting to the tree (the kernel patch
is particularly useful because it allows a modified netstat to run
without being setgid kmem)?
ben
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980325112144.20157.qmail>