RE: Chapter 46: preamble length
Brad,
If an implementation chose to work in such a way that it needed to delete
preamble, I believe it would be non-compliant. I can't think of any reason
why an implementation would need to shrink preamble when devices are
operating within the spec'ed clock tolerance. There is plenty of idle
available. Also, there are at most 4 preamble bytes per a frame that could
be deleted at all while there can be as many as 6 devices in the link doing
clock compensation (4 XGXS plus 2 PCS). An ability to delete preamble
doesn't do much to accelerate a device's ability to delete.
Also, the difference in maximum length packet duration between the fastest
clock and the slowest clock (not counting WAN data rate adjustment because
extra idles are added to provide for it) is 2.44 bit times. If an
implementation still has a column of FIFO storage left when it hits the high
water mark, it can afford to wait 13 packets for an opportunity to delete.
If the existing text in clause 46 is causing PHY designers to think that the
spec allows PHY components to delete preamble, then I may have to rethink my
stance on this issue and support removing the text regarding the RS receiver
tolerating /S/ and SFD in the same column.
Regards,
Pat
-----Original Message-----
From: Booth, Bradley [mailto:bradley.booth@intel.com]
Sent: Wednesday, March 28, 2001 5:54 PM
To: stds-802-3-hssg@ieee.org
Subject: RE: Chapter 46: preamble length
Pat,
I agree that within the context of what we have document in 802.3ae, that we
are allowing for adjustments of clock difference only by deleting idles and
not preamble. I can think of a case with our new minimum IPG over XAUI that
depending on the structure of the implementation for compensating for clock
tolerances, that an implementer could be forced to shrink the preamble due
to the inability to shrink the IPG. I personally thought the WAN PHY might
see this issue too, but that was only a personal opinion. Others may have
differing opinions on the need for shrinkage of preamble, and I fully
understand and accept that because it is based on how you wish to implement
802.3ae.
I admit that the discussion has moved away from the real question, and I've
done a very poor job of keeping the focus on the MAC's need to receive 8
bytes of preamble. The case is that IPG and preamble are permitted to
shrink, and if you believe that there is any possibility that could happen,
then you need to design for it. Preamble's use is not the same now as it
was when it was originally specified; although, I'm sure I don't have to
tell you that, as you have more experience with Ethernet than I do. The
fact is that in GbE I saw some implementers design their MACs to only
receive Ethernet packets with 8 bytes of preamble, when the standard
actually permitted 7 bytes of preamble. My point is that even if the
transmitter specifies sending 8 bytes, the receiver just discards them.
Cheers,
Brad
-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Wednesday, March 28, 2001 6:05 PM
To: bbrown@amcc.com; stds-802-3-hssg@ieee.org
Subject: RE: Chapter 46: preamble length
Ben,
Brad is mistaken. Nothing can change the preamble length. Adjustment for
clock difference is done only by deleting idles or, when continuous ordered
sets are being received, ordered sets.
Pat
-----Original Message-----
From: Ben Brown [mailto:bbrown@amcc.com]
Brad,
Just to correct something you said: "In 10GbE, truncation of the
preamble can occur due to the asynchronous timing associated with
the WAN PHY." If bits are lost in the WAN, the 66-bit blocks are
going to be corrupted and the PCS will lose sync. There is nothing
that currently affects the length of the preamble. If this is not
the case, please educate me.
Ben
"Booth, Bradley" wrote:
>
> Sanjeev,
>
> 10GbE does not support CSMA/CD. In half duplex implementations, some
> preamble bits could be lost due to sampling, asynchronous timing and clock
> recovery effects. From my understanding, the preamble was also to permit
> the Manchester encoder/decoder to lock to the incoming stream.
>
> In a full duplex system without manchester encoding (like GbE and 10GbE),
> the need for all the preamble bits is greatly decreased. Some GbE MACs
were
> designed to be able to receive SFD immediately following the reception of
> one byte of preamble. In 10GbE, truncation of the preamble can occur due
to
> the asynchronous timing associated with the WAN PHY.
>
> Cheers,
> Brad
>
> -----Original Message-----
> From: Sanjeev Mahalawat [mailto:sanjeev@cisco.com]
> Sent: Wednesday, March 28, 2001 12:09 PM
> To: Booth, Bradley; stds-802-3-hssg@ieee.org
> Subject: RE: Chapter 46: preamble length
>
> Booth,
>
> At 08:39 PM 03/27/2001 -0800, Booth, Bradley wrote:
> >
> >Sanjeev,
> >
> >You may wish to re-read 802.3, as Ethernet has always had
> the ability to
> >shorten the preamble. This was very true in the CSMA/CD
> half duplex days of
> >Ethernet, and it has remained a part of full duplex
> Ethernet. The transmit
> >side of the MAC generates the full preamble, but the
> receive side never
> >requires reception of the full preamble.
>
> Does 10GE supports CSMA/CD? Has everything been same in
> 802.3's
> every version of Ethernet? What is the reason in 10GE for
> preamble to be shortnened?
> Are you suggesting that there is no reason but just
because
> it was so in the older
> versions, therefore, 802.3ae HAS to allow preamble to be
> truncated?
>
> And though many things have been added and/or removed from
> version to version BUT preamble has to be allowed to be truncated without
> any reason, right? If this is the case then I do not have any further
> question.
>
> Thanks,
> Sanjeev
>
> >
> >Cheers,
> >Brad
> >
> > -----Original Message-----
> >From: Sanjeev Mahalawat [mailto:sanjeev@cisco.com]
> >Sent: Tuesday, March 27, 2001 8:08 PM
> >To: Grow, Bob; 'Danielle Lemay';
> stds-802-3-hssg@ieee.org
> >Subject: RE: Chapter 46: preamble length
> >
> >
> >Hi Bob,
> >
> >At 02:21 PM 03/27/2001 -0800, Grow, Bob wrote:
> >>
> >>On transmit, a conforming implementation will send seven
> preamble plus the
> >>SFD.
> >>
> >>On receive, there is no current function that will
change
> that length, but
> >>the concensus of the committee was to keep the option
> open. (In 802.3z we
> >>did change preamble length for idle alignment.) The
D3.0
> text should make
> >>it clear that an implementation should be tolerant to
> changes in preamble
> >>length, though it can still rely on lane alignment
(Start
> in lane 0, SFD in
> >>lane 3). Text was added to warn that the Start and SFD
> could appear in the
> >>same column.
> >
> >What is the reasoning behind letting a layer lower than
> >MAC to touch the preamble?
> >
> >Since preamble is coded as data it belongs to MAC
> >and no lower layer should be allowed to change
> >and/or remove the length of preamble.
> >
> >Thanks,
> >Sanjeev
> >
> >
> >>
> >>--Bob Grow
> >>
> >>-----Original Message-----
> >>From: Danielle Lemay [mailto:dlemay@nishansystems.com]
> >>Sent: Monday, March 12, 2001 10:38 AM
> >>To: stds-802-3-hssg@ieee.org
> >>Subject: Chapter 46: preamble length
> >>
> >>
> >>
> >>
> >>
> >>Is it possible for the preamble+SFD to be less than 8
> bytes ?
> >>
> >>thanks,
> >>Danielle
> >>
> >>
> >>
> >>*******************************************
> >>Danielle Lemay
> >>Design Engineer, Nishan Systems
> >>dlemay@NishanSystems.com
> >>408-519-3985
> >>
> >
--
-----------------------------------------
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
-----------------------------------------