Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Chapter 46: preamble length





Brad,

In my opinion, after reading the drafts, I would say that an
implementation which chose to change the length of the preamble,
for any reason, would be non compliant. I think you would
disagree with this statement. I wonder how many others would
disagree with it. Also, where in the draft does it allow an
implementation to change the length of the preamble?

Ben

"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
> -----------------------------------------


-- 
-----------------------------------------
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
-----------------------------------------