| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
-----Original Message-----
From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
Sent: Thursday, December 21, 2000 11:43 AM
To: 'Manish D. Agrawal'; Boaz Shahar; THALER,PAT (A-Roseville,ex1); HSSG
Subject: RE: delay constraints from XGMII to XAUIYes.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 XAUIHello 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 XAUIManish,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 XAUIHello 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]
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 MDIThe 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]
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]
> 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]
> > 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
> Santa Clara, CA 95054 http://www.nSerial.com
>