Scrambling vs. Block Coding
- To: Paul Bottorff <pbottorf@xxxxxxxxxxxxxxxxxx>
- Subject: Scrambling vs. Block Coding
- From: Rich Taborek <rtaborek@xxxxxxxxxxxxxxxx>
- Date: Mon, 10 May 1999 15:54:34 -0700
- CC: "Thirion,Walt" <WThirion@xxxxxxxxxxxx>, "Grivna,Ed" <elg@xxxxxxxxxxx>, HSSG_reflector <stds-802-3-hssg@xxxxxxxx>
- Organization: Transcendata, Inc.
- References: <3.0.32.19990510143422.00b921b0@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Reply-To: rtaborek@xxxxxxxxxxxxxxxx
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
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