> Subject: Re: Suggestion for /proc/net/dev: Additional field "Bandwidth"
>
> > This may not be for the kernel's own sake, but for applications that could
> > make use of such a piece of information.
>
> And could load it from a user configured file. Contrary to rumour many
> network devices don't know their speeds. You also need to keep rx/tx speed
> seperately and know if its half duplex.
Thanks for stating this Alan.
To be more precise: there is no standard way to read the current data rate
from a MII transceiver. And even on transceivers that provide this info,
it's expensive to read the MII management registers -- up to 100us. each.
It's even possible that a non-Ethernet MII transceiver might be built that
has an unusual or variable data rate.
In addition I would like to implore people to *not* extend /proc/net/dev.
When I wrote that code I wanted it to fit in 80 columns, so I summarized a
few error fields. In retrospect that was something of a mistake. The
summarized fields makes it more difficult to isolate problems. It's not as
bad as the simplistic "good stuff / bad stuff" count that BSDs keep, but
when people have problems they usually need to know the exact error type.
Over the years I avoided changing /proc/net/dev because it would both break
programs that depended on the format and make the column-oriented output
unreadable for most people. Unfortunatlely the 2.1.* change of adding byte
counts had both of these undesireable effects, and it broke them *without*
emitting the additional fields! We should not repeat this error by
adding even more info fields to /proc/net/dev. IMHO, we should revert
/proc/net/dev to its old format, and have a new /proc/net/??? output that
emits more complete (SNMP-II/MIB) device-level info, including the station
address and perhaps a best-guess at the current media type/speed.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
-
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/