RE: Chapter 46: preamble length
Good question. I think discussion is really about what value-add you think
the preamble has. The only thing preamble permits 10GbE to do is mark SPD
(start of packet delimiter) or /S/. The receive MAC never sees the /S/,
only preamble. If you require 8 bytes of preamble, then you're going to
count/track to make sure that the eight bytes are there, even though MAC
only discards them. If the receive MAC is designed to trigger on the SFD,
rather than the first byte of preamble, then you have no need to track
preamble and you can treat it like idle codes; therefore, it doesn't matter
how many bytes of preamble you do or don't receive. As for burden, it would
solely depend on your implementation.
Non-compliance is unlikely to be an issue, because we're talking about the
receive MAC. If we (the task force) truly feel that all 8 bytes of preamble
are going/required to show up at the receive MAC, then if your receive MAC
is designed for all 8 bytes of preamble or no bytes of preamble will make no
difference.
Cheers,
Brad
-----Original Message-----
From: Danielle Lemay [mailto:dlemay@xxxxxxxxxxxxxxxxx]
Sent: Thursday, March 29, 2001 3:03 PM
To: pat_thaler@xxxxxxxxxxx; bradley.booth@xxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
Subject: RE: Chapter 46: preamble length
All,
If no device is permitted to cause preamble shrinkage,
then why require MACs to receive frames with shorter
preambles ?
As the Draft 3.0 is written, it requires MACs to be capable
of
receiving frames with any preamble length n+4 (where n= 0 to
??) so
long as the /S/ and /SFD/ are in their proper lanes.
Isn't this an unnecessary burden on implementation?
An invitation for non-compliance ?
thanks,
Danielle
*******************************************
Danielle Lemay
Design Engineer, Nishan Systems
dlemay@xxxxxxxxxxxxxxxxx
408-519-3985
> -----Original Message-----
> From: pat_thaler@xxxxxxxxxxx
[mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Thursday, March 29, 2001 10:48 AM
> To: bradley.booth@xxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> Subject: RE: Chapter 46: preamble length
>
>
>
> Brad,
>
> Since we seem to be taking a poll - I agree with Brad. Any
> device causing
> preamble shrinkage in 10 Gig Ethernet would be
non-compliant.
> All the data
> manipulating physical layers (meaning those that handle
encoding and
> decoding) have state machines specifying how the encoding
> takes place and
> those state machines show that when data is received, the
> data is encoded
> and sent. We have text that explicitly allows deleting
idles
> and, in some
> circumstances, ordered sets. We don't have any text
allowing
> deletion of any
> kind of data and the layers below the RS have no
knowledge
> of preamble.
> WIS, the PMAs, and the PMDs do not do deletion.
>
> Furthermore, we have made sure that there are plenty of
idles
> available for
> deletion. On the other hand, preamble is only 8 bytes and
> deletions can only
> be done in 4 byte chunks. If devices were relying on the
> ability to delete
> preamble, there is only one chance per frame so if a
device
> higher on the
> stack deleted one, there are no chances per frame.
>
> If you believe that the current draft text allows deletion
of
> preamble, then
> it also allows deletion of an arbitrary 4 bytes of data
> because there is no
> text in any of the PCS clauses that treats preamble
> differently than any
> other data byte.
>
> Also, note that if a device deleted preamble, it would be
a
> different kind
> of deletion. Normally deletion happens to a column of idle
or
> an ordered
> set. Neither of the preamble containing columns is
deletable
> because one
> contains the /S/ and the other contains the SFD. An
> implementation deleting
> preamble would have to delete some bytes from one column
and
> some from the
> next column combining the ends of the columns to make a
new column.
>
> Regards,
> Pat
>
> -----Original Message-----
> From: Booth, Bradley [mailto:bradley.booth@xxxxxxxxx]
> Sent: Thursday, March 29, 2001 8:02 AM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: RE: Chapter 46: preamble length
>
>
>
> Ben,
>
> Yes, I would disagree with that. I agree with what Pat
said about MAC
> transmitter being required to send the full preamble, but
the
> MAC receiver
> being tolerant to preamble shrinkage. I remember that
> Gigabit Ethernet MAC
> receivers that were designed for only 8 bytes of preamble,
> even though the
> standard permitted 7, had some interoperability problems
with
> systems that
> occasionally generated 7 bytes of preamble. Thankfully,
the
> UNH IOL caught
> these issues in a non-biased manner.
>
> As for where in the draft, I don't think there is any text
> that directly
> tells you how to do preamble shrinkage. There is text that
> describes the
> occurrence of preamble shrinkage (hence this thread).
> Another question
> would be: is there any text in the draft that strictly
> forbids preamble
> shrinkage?
>
> Cheers,
> Brad
>
> -----Original Message-----
> From: Ben Brown [mailto:bbrown@xxxxxxxx]
> Sent: Wednesday, March 28, 2001 10:44 PM
> To: stds-802-3-hssg@xxxxxxxx
> Subject: 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
>
>
>