RE: WWDM vs. 10Gb/s serial
- To: Mick Seaman <mick@xxxxxxxxxxx>, Paul Bottorff <pbottorf@xxxxxxxxxxxxxxxxxx>, elg@xxxxxxxxxxx, stds-802-3-hssg@xxxxxxxx
- Subject: RE: WWDM vs. 10Gb/s serial
- From: pbottorf@xxxxxxxxxxxxxxxxxx (Paul Bottorff)
- Date: Mon, 10 May 1999 15:51:37 -0700
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
It is 1 / (2**70) for randomized data. A properly designed scrambler system
produces completely random line data independent from the data being
transmitted. A constant string of zeros or any fabricated packet can be
encoded but the line data will still random.
At 03:50 PM 5/10/99 -0700, Mick Seaman wrote:
>A string of 70 zero's does not have a 1/2**70 chance of occuring.
>Zeros and other particular repeating patterns are really much more common
>than that, as a look at carefully initialized memory will show. There should
>be no restriction on transferring memory maps on any other particular data
>Any statistical argument has to very carefully assess assumptions as to
>distribution and independence of variables.
>> -----Original Message-----
>> From: pbottorf@xxxxxxxxxxxxxxxxxx [SMTP:pbottorf@xxxxxxxxxxxxxxxxxx]
>> Sent: Monday, May 10, 1999 4:34 PM
>> To: elg@xxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
>> Subject: RE: WWDM vs. 10Gb/s serial
>> Ethernet has been non-deterministic since inception. Even though some
>> probability exists of generating a long sequence of zeros causing PLL
>> failure the chances can be low enough to fit within the data error rate. A
>> string of 70 zeros has only a 1 / (2 ^ 70) chance of occurring. On a
>> scrambled 10 GigE link a zeros string would happen once every 3000 years
>> Of course the PLLs must be much more rigid for the scrambler solutions
>> allowing the PLL to hold lock over short periods of imbalance. Since there
>> is no longer a need for Ethernet to have rapid phase lock the more rigid
>> PLL with a long acquistion time should not present a design problem.
>> The problem of transparency can be solved in a variety of ways. One
>> is to use a variation of the HEC check algorithm to create a
>> <lenght><type><check> field for delimiting both frames and special
>> sequences like idle and management. The time required for these algorithms
>> to settle on a frame can also be relatively fast if the <check> sequence
>> The overhead of 8/10 is 25% not 20% which translates to as much as a 33%
>> reduction in reach. Scrambling is a perfect solution to reduce the cost of
>> data networks especially in the wide area. In the local area scrambling
>> also help contain the transmission frequencies improving the distance of
>> any given technology.
>> At 01:54 PM 5/10/99 -0500, Ed Grivna wrote:
>> >Paul A. Bottorff wrote:
>> >> Bill:
>> >> I certainly agree that the PHY must provide fast failure detection (<10
>> >> msec). In addition, it would be nice if the PHY layer could inform the
>> >> transmitting end of failures.
>> >> 10 GigE has a broad range of uses for both LAN and WAN applications.
>> >> design tradeoffs for photonics in the WAN and LAN are different. In the
>> >> a major component of cost is the optical reach. The data which I've
>> >> indicates that transmission frequency very significantly affects reach.
>> >> get the lowest cost solutions 10 GigE should move away form group codes
>> >> systems like 8/10 into scrambler code systems. Scrambling provides an
>> >> efficient line encode giving 10 gigabits of data at 10 gigabaud.
>> >While scrambling is an efficient way of dealing with data, it is also
>> >non-deterministic in how that data is handled. Given any scrambling
>> >polynomial and an uncontrolled data stream, it is always possible to
>> >zero out the scrambler. Once this happens, there are NO transitions
>> >in the serial stream until new data containing 1's is present to
>> >re-seed the scrambler.
>> >The SMPTE-259 serial interface recognized this problem a long time ago
>> >and requires the characters in the video field to be between 004h
>> >and 3FBh. Even with these limitations, they can wind up with long
>> >repeating patterns of 19 zero bits followed by a single 1-bit (or 19
>> >one bits follwed by a single 0-bit). These signals have a very high
>> >DC content (making it difficult to send through an AC-coupled channel).
>> >An alternate pattern that they see consists of an alternating 20
>> >0-bits followed by 20 1-bits (which generates a square wave). These
>> >are all referred to as the SMPTE pathalogical patterns (see ANSI/SMPTE
>> >RP-178-1996). They are nasty to handle, both for the interface
>> >circuitry AND for the PLLs.
>> >Since there is no control over the content of the data field in Ethernet
>> >packets, and the fact that many records are padded with trailing zeros,
>> >I feel that the usage of a scrambler would not be condusive to good
>> >engineering practices for THIS application. As the data rate is
>> >the time penalty and system-level impact required to recover from
>> >data errors becomes much more significant. If the scrambler ever did
>> >zero out, the PLL would most surely drift by at least one bit.
>> >Once that happend framing must occur again to start processing data.
>> >But frameing is no longer simple either. Unlile a block code (such as
>> >8B/10B) where not all characters are valid and extra chracters are
>> >present for in-band signalling, scrambled codes use all possible
>> >characters. This carries numerous implications.
>> >First, framing must be done using combinations of data characters.
>> >In telecom environments they identify a specific sequnce oc data
>> >characters and the specific period in which they must occur. Once these
>> >characters are found numerous times in that location, framing is
>> >declared to be achieved. Unfortunately, nothing prevents these specific
>> >characters from being part of the data field, where they may also
>> >occur on the same bopundaries.
>> >Since Ethernet is also not based on fixed length records or records that
>> >are sent on a continuous basis on the same boundary, performaing framing
>> >with a scrambled codeing will be quite difficult. Because it requires
>> >multiple recognitons of the pattern to validate the framing, it also
>> >takes a lot of time. All this to handle errors that are GUARENTEED
>> >to happen because of the uncontroled nature of the data streem contents.
>> >This makes the handling of errors much more onerous on the system. Its
>> >bad enough that the lost data may have to be resent, but the system
>> >level impact is much more than just the time necessary to re-transmit.
>> >802.3z chose a block coded interface for mutiple reasons, including those
>> >listed here. Yes there is a penalty in symbol rate to deal with this,
>> >but generally the 20% adder is significantly easier to handle than the
>> >baggage that comes with a scrambled interface.
>> >By changing to a scrambler, this also makes the optics much more
>> >to design and more expensive to build. Most cannot handle even a limited
>> >unbalance in the data stream. They are usually AC-coupled to limit the
>> >noise gain in the receiver. The clock/data recovery PLLs are also more
>> >difficult and must be much more stable.
>> >Ed Grivna
>> >Cypress Semiconductor
>> >> Paul
>> >> Paul A. Bottorff
>> >> Director Switching Architecture, Bay Architecture Lab
>> >> Nortel Networks, Inc
>> >> pbottorf@xxxxxxxxxxxxxxxxxx