Re: Chapter 46: preamble length
Brad, all:
As the person who raised the comment that had the clarification inserted
into the draft at D2.3, I've been watching this thread with varying
amounts of interest, amusement and fear during the discussion.
Your second paragraph below describes exactly what I was trying to
achieve with the comment: I am completely aware that current PHY types
cannot modify the preamble length on receive and to that extent is
"redundant", but I cannot see into the future any better than anyone
else can, and I don't see the point in painting ourselves into a
specification corner when, for very little cost in logic, we can allow
ourselves the possibility of adding PHY types which do shrink (or
indeed extend, which is also permitted by clause 46) the preamble.
Cheers
Gareth
--
/ /\/\ Gareth Edwards mailto:gareth.edwards@xxxxxxxxxx
\ \ / Design Engineer
/ / \ System Logic & Networking Phone: +44 131 666 2600 x234
\_\/\/ Xilinx Scotland Fax: +44 131 666 0222
"Booth, Bradley" wrote:
>
> 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@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Wednesday, March 28, 2001 6:05 PM
> To: bbrown@xxxxxxxx; stds-802-3-hssg@xxxxxxxx
> 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@xxxxxxxx]
>
> 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@xxxxxxxxx]
> > Sent: Wednesday, March 28, 2001 12:09 PM
> > To: Booth, Bradley; stds-802-3-hssg@xxxxxxxx
> > 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@xxxxxxxxx]
> > >Sent: Tuesday, March 27, 2001 8:08 PM
> > >To: Grow, Bob; 'Danielle Lemay';
> > stds-802-3-hssg@xxxxxxxx
> > >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@xxxxxxxxxxxxxxxxx]
> > >>Sent: Monday, March 12, 2001 10:38 AM
> > >>To: stds-802-3-hssg@xxxxxxxx
> > >>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@xxxxxxxxxxxxxxxxx
> > >>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@xxxxxxxx
> -----------------------------------------