Re: Clause 46 - Preamble
OK, although we agree that preamble shrink is largely moot at 10G for
the PHYs currently defined, I'm going to raise a comment to clarify the
wording of the subclause slightly so that it is explicitly consistent
with slower speeds; if it gets knocked down at the plenary, so be it.
Thanks, everyone, for your help.
Cheers
Gareth
pat_thaler@xxxxxxxxxxx wrote:
>
> None of the PHYs we are defining are allowed to shrink preamble.
>
> Pat
>
> -----Original Message-----
> From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
> Sent: Friday, February 16, 2001 1:10 PM
> To: Shimon Muller; stds-802-3-hssg@xxxxxxxx
> Subject: RE: Clause 46 - Preamble
>
> Shrinking IPG to 4 byte and also having an option
> that makes a PHY implementaion valid that can just
> give an /S/ and SFD (shrink preamble) will create issues.
> (One may argue that it is not different than its precedent,
> but there were reasons for it in the precedent and there are lots
> of things are dropped or changed from the precedents).
> With the current ASIC/Memory technologies to get this kind of
> BW (though instantaneos) may not be an easy task.
>
> If there may be implementations those just could
> assume that no PHYs are shriking the preamble and design
> the RS with the wrong assumption if you keep an option.
>
> And also if there is no good reason as to why a PHY would
> shrink preamble, then why keep an option.
>
> Thanks
> -Sanjeev
>
>
> At 11:53 AM 02/16/2001 -0800, Shimon Muller wrote:
> >
> >> I would think keeping an option to change the preamble size
> >> by a PHY may lead to confusion and PHY/RS/MAC un-interoperable
> >> implementations. It is not a restriction but an explicit specification
> >> that would keep all the PHYs and RS implementations STANDARD.
> >
> >
> >The length of the preamble has no interoperability implications.
> >This "option" has always been in our standard. The intent of my comment
> >#252 has been exactly that: not to eliminate it for 10Gb/s operation.
> >
> >The way the MAC is defined, the receiver is supposed to wait for the
> >arrival of the SFD to recognize a valid MAC frame. If the SFD does not
> >arrive, the frame "never happened". Furthermore, we have always allowed
> >the preamble to shrink. Although we do not expect this to happen this
> >time, there is no good reason to disallow it.
> >
> >
> > Shimon.
> >