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@mindspring.com]
> 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@mysticom.com]
> >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@pune.coreel.com]
> >>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@mysticom.com]
> >>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@pune.coreel.com]
> >>>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@agilent.com>mailto:pat_thaler@agilent.com]
> >>>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@mysticom.com>mailto:boazs@mysticom.com]
> >>>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@earthlink.net>mailto:rtaborek@earthlink.net]
> >>> > 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@siliconbridge.com>mailto:ss_shen@siliconbridge.com]
> >>> > > Sent: Wednesday, December 13, 2000 11:58 AM
> >>> > > To: stds-802-3-hssg@ieee.org
> >>> > > 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@nSerial.com>mailto:rtaborek@nSerial.com
> >>> > 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@amcc.com
-----------------------------------------