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

RE: delay constraints from XGMII to XAUI




Ben,

That is my implication.  I believe that the original intent of .3x flow
control breaks down when we talk about a WAN link that spans multiple
sections and lines.  From the MAC perspective, you are correct that these
are just as point-to-point as a 3 meter jumper, but from the PHY perspective
where the majority of the delay timing is calculated, this are links are
vastly different.  I wasn't around when .3x flow control was invented, so
those with firt hand knowledge could speak better to the original intent.

The key point that I was trying to make is the MDI-MAC delay constraints are
more important in short links where the delay of the link is not orders of
magnitude greater than the MDI-MAC delay.

Cheers,
Brad

-----Original Message-----
From: Ben Brown [mailto:bbrown@xxxxxxxx]
Sent: Saturday, December 23, 2000 8:19 PM
To: 802.3ae
Subject: Re: delay constraints from XGMII to XAUI




Brad,

I just wanted to pick up on something you wrote:

"Booth, Bradley" wrote:
> 
> Flow control is also only for point-to-point links.
> 

I hope you aren't implying that a WAN link with multiple
lines & sections (do I have the nomenclature correct?) is
not a point-to-point link. From an ethernet MAC perspective,
these are just as point-to-point as a 3 meter jumper.

I can't even begin to imagine the amount of buffering
required to run .3x flow control over such a link. I would
be interested in a short note from someone with experience
regarding what kind of potential latencies such a link
might have.

Thanks,
Ben

"Booth, Bradley" wrote:
> 
> Time to hit the RESET button on this one. :-)
> 
> First, you are correct in the assumption that a 40km link buffer
requirement
> (1MB, not Mbit) will greatly exceed the internal latency.
> 
> Not everyone in the world will design equipment to work up to 40km.  Some
> will create equipment that works up to 65m, and to optimize that
equipment,
> they're not going to want to have 1MB of buffering just for flow control
> (that would be overkill).  In these short distance applications, knowing
the
> maximum latency in the link partner device and in the local device will
> permit designers to optimize their flow control buffering.
> 
> Flow control is also only for point-to-point links.
> 
> Happy holidays,
> Brad
> 
>                 -----Original Message-----
>                 From:   Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
>                 Sent:   Friday, December 22, 2000 10:31 AM
>                 To:     Manish D. Agrawal; Boaz Shahar; Manish D. Agrawal;
> THALER,PAT (A-Roseville,ex1); HSSG
>                 Subject:        RE: delay constraints from XGMII to XAUI
> 
>                 Manish,
> 
>                 One of the issue of the delay is that there are other
> distances
>                 involved.  The 850nm 65m PHY will not have the same
> transmission media
>                 latency as the 1500nm 40km PHY.  Add latency due to long
> haul optical
>                 services for the WAN PHY and you have got even more issues
> with flow
>                 control response latency.  These are going to be issues of
> discussion as we
>                 go forward.
> 
>                 Thank you,
>                 Roy Bynum
> 
>                 At 11:32 AM 12/22/00 +0530, Manish D. Agrawal wrote:
>                 >Hello Boaz,
>                 >
>                 >As you said  "The only MAC requirement I can think of for
> bounding the
>                 >lower layer delay  is for buffer sizing for 802.3x flow
> control.  That has
>                 >been the factor for  keeping the delay tables in various
> clauses. "
>                 >
>                 >But, since the delay for the flow control seems to be
> greater than 1 Mbit,
>                 >why there are delay constraints of 256/212/272 bits in
> various clauses,
>                 >which are negligible as compared to the delay of 40KM
> fiber?
>                 >
>                 >Correct me if I am wrong.
>                 >
>                 >Best Regards,
>                 >Manish
>                 >-----Original Message-----
>                 >From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
>                 >Sent: Thursday, December 21, 2000 3:13 PM
>                 >To: 'Manish D. Agrawal'; Boaz Shahar; THALER,PAT
> (A-Roseville,ex1); HSSG
>                 >Subject: RE: delay constraints from XGMII to XAUI
>                 >
>                 >Yes.
>                 >The max delay occures when MAC(1) informed about the need
> for stop_rx from
>                 >higher layer just at the beginning of MAX sized frame
> transmission, and
>                 >similarly, MAC(2) get the pause just at the beginning of
> max frame
>                 >transmission.
>                 >
>                 >However, as already noted here, this is negligible
compare
> to the delay of
>                 >40KM fiber, which is more then 1Mb.
>                 >
>                 >Boaz Shahar, MystiCom.
>                 >>-----Original Message-----
>                 >>From: Manish D. Agrawal [mailto:manish@xxxxxxxxxxxxxxx]
>                 >>Sent: Thursday, December 21, 2000 10:21 AM
>                 >>To: Boaz Shahar; Manish D. Agrawal; THALER,PAT
> (A-Roseville,ex1); HSSG
>                 >>Subject: RE: delay constraints from XGMII to XAUI
>                 >>
>                 >>Hello Boaz,
>                 >>
>                 >>As for as I see, the time-point of pause command
assertion
> by MAC(1)
>                 >>until this pause command is actually executed by MAC(2)
is
> also dependent
>                 >>upon the transmitter status of the MAC(1) and MAC(2).
Let
> us take an
>                 >>example : MAC(1) is in the process of transmitting a
frame
> of about 1500
>                 >>bytes and it saw pause command assertion. The MAC(1)
first
> completes its
>                 >>frame transmission and then only it transmits the PAUSE
> frame. Similarly
>                 >>when MAC(2) is in process of transmitting a frame of
about
> 1500 bytes and
>                 >>it receives the PAUSE frame, then it first completes its
> frame
>                 >>transmission before executing PAUSE. So this delay is
not
> the
>                 >>only  linear delay of transfer between the MACs.
>                 >>
>                 >>am I right Boaz?
>                 >>
>                 >>Best Regards,
>                 >>Manish
>                 >>-----Original Message-----
>                 >>From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
>                 >>Sent: Thursday, December 21, 2000 2:38 AM
>                 >>To: 'Manish D. Agrawal'; THALER,PAT (A-Roseville,ex1);
> Boaz Shahar; HSSG
>                 >>Subject: RE: delay constraints from XGMII to XAUI
>                 >>
>                 >>Manish,
>                 >>SInce there is no colision, the only effect of the MAC
to
> MAC delay is
>                 >>the size of the buffer which stores packets from the
> time-point of pause
>                 >>command assertion by MAC(1) until this pause command is
> actually executed
>                 >>by MAC(2). This is linear with the delay of transfer
> between the MACs.
>                 >>
>                 >>Boaz Shahar, MystiCom.
>                 >>>-----Original Message-----
>                 >>>From: Manish D. Agrawal [mailto:manish@xxxxxxxxxxxxxxx]
>                 >>>Sent: Wednesday, December 20, 2000 8:38 PM
>                 >>>To: THALER,PAT (A-Roseville,ex1); Boaz Shahar; HSSG
>                 >>>Subject: RE: delay constraints from XGMII to XAUI
>                 >>>
>                 >>>Hello Pat,
>                 >>>
>                 >>>Can you clarify, what you exactly mean by the delay
> between
>                 >>>XGMII to XGMII (MAC reaction time to the flow control).
>                 >>>
>                 >>>Boaz, as you says "The only MAC requirement I can think
> of for bounding the
>                 >>>lower layer delay is for buffer sizing for 802.3x flow
> control."
>                 >>>About which buffer you are talking about? and how it
> relates with the
>                 >>>delay constraints?
>                 >>>
>                 >>>Best Regards,
>                 >>>Manish
>                 >>>
>                 >>>-----Original Message-----
>                 >>>From: THALER,PAT (A-Roseville,ex1)
> 
> >>>[<mailto:pat_thaler@xxxxxxxxxxx>mailto:pat_thaler@xxxxxxxxxxx]
>                 >>>Sent: Friday, December 15, 2000 12:58 AM
>                 >>>To: Boaz Shahar; HSSG
>                 >>>Subject: RE: delay constraints from XGMII to XAUI
>                 >>>
>                 >>>
>                 >>>
>                 >>>Boaz,
>                 >>>
>                 >>>If there is a compatibility interface such as XAUI,
then
> one needs to
>                 >>>define
>                 >>>how much delay is on either side of it. Therefore one
> needs to spec at
>                 >>>least
>                 >>>the following:
>                 >>>   XGMII to XGMII (MAC reaction time to the flow
> control).
>                 >>>   XGMII to XAUI
>                 >>>   XAUI to XBSI
>                 >>>   XBSI to MDI
>                 >>>
>                 >>>The point of compatibility interfaces is to define an
> interface where
>                 >>>components independently designed can be compatible
when
> mated at that
>                 >>>interface. Therefore, a budget can't be specified for
the
> total without
>                 >>>providing a breakdown with respect to the compatibility
> interfaces. If a
>                 >>>compatibility interface is not physically instantiated
> then the device has
>                 >>>to meet the total but it is up to the device how to
> allocate that total.
>                 >>>
>                 >>>For instance, if a device had an XGMII and an MDI, then
> it would have to
>                 >>>meet the sum of the three delays: XGMII to XAUI, XAUI
to
> XBSI and XBSI to
>                 >>>MDI.
>                 >>>
>                 >>>One way to specify this is to specify the delay for
each
> sublayer and say
>                 >>>that the total between compatibility interfaces need to
> meet the total for
>                 >>>the sublayers between them.
>                 >>>Since this delay is only important for the flow
control,
> I recommend we
>                 >>>choose values that are easy to meet and specify them
per
> sublayer. No
>                 >>>matter
>                 >>>what we do, our delays will be long in bit times
compared
> to the lower
>                 >>>speeds because our paths so wide. There is no reason to
> tweak the delays to
>                 >>>shave a few byte times.
>                 >>>Regards,
>                 >>>Pat
>                 >>>
>                 >>>-----Original Message-----
>                 >>>From: Boaz Shahar
> [<mailto:boazs@xxxxxxxxxxxx>mailto:boazs@xxxxxxxxxxxx]
>                 >>>Sent: Thursday, December 14, 2000 12:43 AM
>                 >>>To: HSSG
>                 >>>Subject: RE: delay constraints from XGMII to XAUI
>                 >>>
>                 >>>
>                 >>>
>                 >>>Hi,
>                 >>>I think that the standard should constraint only the
> total delay from the
>                 >>>MDI to the XGMII, and leave internal partitioning to
> implementation.
>                 >>>Boaz
>                 >>>
>                 >>> > -----Original Message-----
>                 >>> > From: Rich Taborek
>                 >>>
> [<mailto:rtaborek@xxxxxxxxxxxxx>mailto:rtaborek@xxxxxxxxxxxxx]
>                 >>> > Sent: Thursday, December 14, 2000 12:18 AM
>                 >>> > To: HSSG
>                 >>> > Subject: Re: delay constraints from XGMII to XAUI
>                 >>> >
>                 >>> >
>                 >>> >
>                 >>> > Bob,
>                 >>> >
>                 >>> > Agreed.
>                 >>> >
>                 >>> > Steven,
>                 >>> >
>                 >>> > Just to carify, the MDI to XGMII delay includes the
> XAUI to
>                 >>> > XGMII delay.
>                 >>> >
>                 >>> > Best Regards,
>                 >>> > Rich
>                 >>> >
>                 >>> > --
>                 >>> >
>                 >>> > "Grow, Bob" wrote:
>                 >>> > >
>                 >>> > > The only MAC requirement I can think of for
bounding
> the
>                 >>> > lower layer delay
>                 >>> > > is for buffer sizing for 802.3x flow control.
That
> has
>                 >>> > been the factor for
>                 >>> > > keeping the delay tables in various clauses.
>                 >>> > >
>                 >>> > > --Bob Grow
>                 >>> > >
>                 >>> > > -----Original Message-----
>                 >>> > > From: Steven Shen
>                 >>>
> [<mailto:ss_shen@xxxxxxxxxxxxxxxxx>mailto:ss_shen@xxxxxxxxxxxxxxxxx]
>                 >>> > > Sent: Wednesday, December 13, 2000 11:58 AM
>                 >>> > > To: stds-802-3-hssg@xxxxxxxx
>                 >>> > > Subject: delay constraints from XGMII to XAUI
>                 >>> > >
>                 >>> > > Hi all:
>                 >>> > >
>                 >>> > > In D2.0 table 48.5 defines the MDI to XGMII delay
>                 >>> > constraints to be 272
>                 >>> > > UI. I wonder that "is there any delay constraints
on
> XAUI to XGMII
>                 >>> > > (PCS+PMA)"?
>                 >>> > >
>                 >>> > > thanks
>                 >>> > >
>                 >>> > > best regards
>                 >>> > >
>                 >>> > > Steven Shen
>                 >>> > > Silicon Bridge Inc.
>                 >>> >
>                 >>> >
> -------------------------------------------------------
>                 >>> > Richard Taborek Sr.                 Phone:
> 408-845-6102
>                 >>> > Chief Technology Officer             Cell:
> 408-832-3957
>                 >>> > nSerial Corporation                   Fax:
> 408-845-6114
>                 >>> > 2500-5 Augustine
>                 >>> Dr.
> <mailto:rtaborek@xxxxxxxxxxx>mailto:rtaborek@xxxxxxxxxxx
>                 >>> > Santa Clara, CA
>                 >>> 95054
> <http://www.nSerial.com>http://www.nSerial.com
>                 >>> >
> 

-- 
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104 
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------