Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Chapter 46: preamble length


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 ?


Danielle Lemay
Design Engineer, Nishan Systems

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