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

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



Title: Re: [EFM] ifSpeed & 2BASE-TL/10PASS-TS
I disagree with using Smartbits as a criteria, but agree with the end conclusion.  There's a ton of other Ethernet interfaces out there and looking at a particular configuration as a guide for what the ifSpeed should be seems like a mistake. 
 
If there ifSpeed is not super accurate, and there is no loss in
   10BASE-T------>10PASS-TS, (e.g. 10Mbps in 10BASE-T > 10 Mbps in 10PASS-TS)
then there is loss from
   10PASS-TS--->10BASE-T
Although there's no smartbits 10PASS-TS port yet, I assume there eventually will be.  So looking at loss in a intermediate device as a criteria/reason doesn't feel right. 
 
That said, using the MII as the point of measurement does feel right (to me anyway).   I'm only concerned that we come up with a consistent and correct way to express this (hence the previous questions/example). 
 
 
-----Original Message-----
From: Edward Beili [mailto:EdwardB@actelis.com]
Sent: Tuesday, August 03, 2004 12:43 PM
To: Hugh Barrass; STDS-802-3-EFM@listserv.ieee.org; Matt Squire
Cc: hubmib@ietf.org
Subject: RE: [EFM] ifSpeed & 2BASE-TL/10PASS-TS

Hugh,
 
I don't really understand your 3+1 option.
 
In my view the criteria shall be as follows:
Suppose you have the following system configuration:
 
[Smartbits]----10BaseT----[EFMCu CO]----2BaseTL-----[EFMCu RT]----10BaseT---[Smartbits]
                    ifSpeed=10Mbps                   ifSpeed=10Mbps                     ifSpeed=10Mbps
 
If the EFMCu link reports its ifSpeed as 10Mbps, provided that the MAC bridge in the EFMCu CO and RT is wire-speed, there should be no packet loss when I fire the Smartbits in full duplex 10Mbps 100% with min IFG with frame length of 64 Bytes and 1518 Bytes.
 
It looks to me that option 3, i.e. sum of modem data rates without 64/65B encapsulation and PAF overhead but with IFG, answers this criteria best.
The reported ifSPeed may not be super accurate, the error however should always be positive, i.e. no possible packet loss in the configuration above. Obviously option 2 (goodput) would work as well.
 
Regards,
-E.
-----Original Message-----
From: owner-stds-802-3-efm@listserv.ieee.org on behalf of Hugh Barrass
Sent: Tue 8/3/2004 7:48 AM
To: STDS-802-3-EFM@listserv.ieee.org
Cc:
Subject: 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
>
>
>