Re: Scrambling vs. Block Coding
I don't think that error extension is a problem for Ethernet. One error will
cause packet retransmission just the same as 3 errors in the packet.
mark sankey wrote:
> 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.
> At 03:54 PM 5/10/99 -0700, you wrote:
> >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,
> >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