Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [EFM] ifSpeed & 2BASE-TL/10PASS-TS



Matt,

I would go with 3) plus 1) - reasons:

0) is just plain wrong!

1) The aggregated links appear to the MAC and upper layers as a single
link. The aggregated link speed governs the rate across the MII.

2) We've never accounted for "goodput" before

3) That's how we have done it for all other PHYs. The overhead of
encapsulation is absorbed by the link running at a faster rate than the
MII (whether it's 4b5b, 8b/10b or 64b/66b). But the effect of the IPG
depends on the frame size, so is ignored.

So, I think it should be the aggregate rate at the MII for an imaginary,
infinite length frame.

Hugh.

Matt Squire wrote:

>I figured I'd fire off a note to the reflectors to get this discussion started.
>
>During the discussions today in the hubmib WG, the question arose as to what should be the ifSpeed for 2BASE-TL & 10PASS-TS interfaces.
>
>Traditionally, it seems the ifSpeed has been tied to the speed of the MAC (e.g. 10Mbps, 100Mbps, etc.).  With 2BASE/10PASS, the PHY may be running at a much lower speed than the 100Mbps MAC, so its not particularly useful to the administrator to call all of these interfaces 100M when the PHYs aren't there.
>
>Options for ifSpeed of 2BASE/10PASS seem to include the following:
>
>0) Use 100 Mbps (MAC speed).
>
>1) Sum the physical date rates of PMEs in the aggregate (PHY speed).
>
>2) Use the rate of "goodput" on the PHYs (e.g. how much data can ge thru).  This would ignore any overhead of the PHY (PAF, 64/65) and overhead of the MAC (preamble, IPG).  This most accurately reflects how much data can get thru.
>
>3) Use the rate at the MAC/MII.  E.g. include preamble/IPG (even though its not transmitted), but not PHY overhead (PAF, 64/65).  This seems consistent with other PHYs, but is kinda weird in that we're not actually transmitting preamble/ipg.
>
>There are probably other options too.  Thoughts/opinions?
>
>- Matt
>
>
>