RE: Augmenting MAU-MIB - was: RE: EFM MIB Internet-Drafts, WG Meetings
"Matt Squire" <[email protected]>
| Newsgroups | gmane.ietf.hubmib |
|---|---|
| Message-ID | <[email protected]> |
Its a fair point. Most of the stats you mention that are not applicable to 2BASE/10PASS are also not applicable on any full-duplex PHY. But in the past, even PHYs that are only full-duplex support the MIB. So I'm going with precedent. Also, I haven't looked at it closely, but aren't some of the half-dup counters applicable because of the way the MAC runs in half-duplex for rate matching? I've seen the implementation specific counters have some very good utility as well. Thats my 2cents. Take it for what its worth. - Matt > Let's look at the statistics. > > Dot3StatsEntry: > - dot3StatsIndex - ifIndex > - dot3StatsAlignmentErrors - would probably be always 0 > for EFMCu, as EFMCu framer > is octet aligned. > - dot3StatsFCSErrors - > - dot3StatsSingleCollisionFrames - always 0, no > collisions in EFMCu > - dot3StatsMultipleCollisionFrames - always 0, no > collisions in EFMCu > - dot3StatsSQETestErrors - always 0, Full-Duplex > - dot3StatsDeferredTransmissions - always 0, Full-Duplex > - dot3StatsLateCollisions - always 0, no > collisions in EFMCu > - dot3StatsExcessiveCollisions - always 0, no > collisions in EFMCu > - dot3StatsInternalMacTransmitErrors - implementation specific > would probably be 0. > - dot3StatsCarrierSenseErrors - always 0, Full-duplex > - dot3StatsFrameTooLongs - > - dot3StatsInternalMacReceiveErrors - implementation specific > would probably be 0. > - dot3StatsEtherChipSet - deprecated > - dot3StatsSymbolErrors - > - dot3StatsDuplexStatus - redundant, given in ifMautype > always Full-Duplex > - dot3StatsRateControlAbility - always No > - dot3StatsRateControlStatus - always Disabled > > Dot3HCStatsEntry is not required for EFMCu interfaces as they > are below > 100Mbps. > > So in the end we have only 3 counters that have any meaning > for an EFMCu > interface: > dot3StatsFCSErrors, dot3StatsFrameTooLongs dot3StatsSymbolErrors > > I agree these are important statistics. However we may decide > to provide > them in the EFM-CU-MIB, especially taking into consideration > that textual > description for these counters should be updated to include > EFMCu specific > explanation (e.g. for dot3StatsSymbolErrors). > > What do you think? > -Edward > >