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