RE: Chapter 46: preamble length
Devendra,
No, I am not indicating that I am aware of ANY PHY
that eats preamble.
Yong.
============================================
Yongbum "Yong" Kim Direct (408)922-7502
Technical Director Mobile (408)887-1058
3151 Zanker Road Fax (408)922-7530
San Jose, CA 95134 Main (408)501-7800
ybkim@xxxxxxxxxxxx www.broadcom.com
============================================
-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Devendra Tripathi
Sent: Thursday, March 29, 2001 10:31 AM
To: Yongbum Kim; Gareth Edwards; Booth, Bradley
Cc: stds-802-3-hssg@xxxxxxxx
Subject: RE: Chapter 46: preamble length
Young,
Are you indicating that there are already PHYs which are eating/using
preamble for
10 G implementation ?
I very much appreciate Steve's comment in this regards that this "option" to
PHY might prove
to be the sleeping interoperability bug which may surface. In general I like
the
idea of being permissive on MAC Rx side but I do not like giving permission
to PHY to
eat/use preamble. At least clause 46 structure (see the table 2,3) does not
seem to
permit this. The lesser the options, the better.
Regards,
Devendra Tripathi
VidyaWeb, Inc
90 Great Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Direct: (408)363-2375
Fax: (408)226-6862
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Yongbum Kim
> Sent: Thursday, March 29, 2001 3:15 AM
> To: Gareth Edwards; Booth, Bradley
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: Chapter 46: preamble length
>
>
>
> Ben and Gareth,
>
> Please heed to what Pat Thaler related to, "be strict on what
> may be transmitted and permissive on what may be receive."
>
> I know that a few implementations take advantage of preamble
> space for their own value-added stuff. Fine. It will be left to the
> group what will be protected by shall for conformance. And I trust
> the group will abide by the words in quotes above. The future discussions
> could be left for 40G or 100G Ethernet discussions. Our job is to define
> 10G Ethernet, and if I were to guess how we would behave in the future,
> based
> on our past behavior, is that we will respect what are installed and would
> not force non-conformance of implementations that are already widely used.
>
> We have enough history of 802 and 802.3. I do not believe we have
> done dis-service to the industry nor the installed base (no matter how we
> did not like the predicament ;-|).
>
> regards,
>
> Yong.
>
> ============================================
> Yongbum "Yong" Kim Direct (408)922-7502
> Technical Director Mobile (408)887-1058
> 3151 Zanker Road Fax (408)922-7530
> San Jose, CA 95134 Main (408)501-7800
> ybkim@xxxxxxxxxxxx www.broadcom.com
> ============================================
>
>
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Gareth Edwards
> Sent: Thursday, March 29, 2001 12:49 AM
> To: Booth, Bradley
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: 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
> > -----------------------------------------
>
>
>