Re: Scrambling vs. Block Coding
Paul, Ed, Rich:
One other problem with scrambling is the method for synchronizing to the
scrambler sequence. For Ethernet, it seems appropriate to use a
self-synchronous scrambling algorithm, like ATM and Packet on SONET.
However, self-synchronous scrambling has the problem of turning one
transmission bit error into N bit errors, where N is the number of terms
(minus one) in the scrambler polynomial. This may not be acceptable.
Mark
At 03:54 PM 5/10/99 -0700, you wrote:
>Paul,
>
>This is great discussion!
>
>I've been around high-speed serial interfaces since my days with IBM
>working on serial link for mainframes. I haven't been exposed to
>scrambling techniques much simply because I'm used to transmission codes
>which address reliable data transport in a substantially different
>fashion. I believe that the same is true for many HSSG'ers coming from
>the datacom side. Hopefully you and other "scramblers" will keep us on
>our toes and ensure that the REQUIREMENTS for reliable data transport
>are met and that all reasonable (coding) methods to meet those
>requirements are thoroughly investigated.
>
>As Paul points out it's all about contain the transmission frequencies,
>thereby improving the distance of any given technology.
>
>--
>
>Paul Bottorff wrote:
>>
>> Ed:
>>
>> 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 or
>> so.
>>
>> 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 example
>> 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 is
>> large.
>>
>> 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 can
>> also help contain the transmission frequencies improving the distance of
>> any given technology.
>>
>> Paul
>
>--
>
>Thirion, Walt wrote:
>>
>> I agree that 8B/10B provides the error detection, etc., but I hope we
>> can come up with a coding that is more bandwidth efficient. Wasting 20%
>> of 10 Gb/s just doesn't seem like a good idea to me.
>>
>> Walter Thirion
>> Vice President, Strategic Technology Development
>> Level One Communications
>> 512-407-2110
>
>--
>
>Best Regards,
>Rich
>
>-------------------------------------------------------------
>Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
>Principal Architect Fax: 650 940 1898 or 408 374 3645
>Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
>1029 Corporation Way http://www.transcendata.com
>Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx
>