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