RE: delay constraints from XGMII to XAUI
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
>>> >