Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: Paul Bottorff <pbottorf@xxxxxxxxxxxxxxxxxx>*Subject*: Re: WWDM vs. 10Gb/s serial*From*: "Mike Dudek" <mdudek@xxxxxxxxxxxx>*Date*: Thu, 13 May 1999 18:11:11 -0600*CC*: stds-802-3-hssg@xxxxxxxx*References*: <3.0.32.19990512134553.0074f420@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>*Sender*: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx

There is another way of looking at the scrambler lock up problem. If we assume the input data is a packet (miscellaneous data) followed by gaps of all zero's, then the lock up problem becomes what is the probability that the last few bits of the packet leave the scrambler in the wrong state. ie one can consider that each packet "stirs" the scrambler and possibly leaves it in the wrong state. You don't have to know the state of the scrambler and feed it the wrong sequence on purpose. The scrambler has 2expN different states one of which is "wrong". ie one would expect on average that once every 2expN packets the scrambler will be left in the bad state. (If however the packet gaps are not all zero then the lock-up problem is much less severe.) Paul Bottorff wrote: > >Date: Wed, 12 May 1999 11:07:29 -0700 > >To: elg@xxxxxxxxxxx (Ed Grivna) > >From: Paul Bottorff <Paul_Bottorff> > >Subject: RE: WWDM vs. 10Gb/s serial > > > >Ed: > > > >Granted if you know the state of the scrambler, the polynomial, and can > insert data in sequence with the scrambler state, then a pattern of at most > 2N bits will zero it, however these assumption are based on full knowledge > and access to the PHY by the source of data. > > > >If anything goes it is much easier to break the PHY by jamming a > screwdriver on the logic lines or pulling the wires out of the box. > > > >Cheers, > > > >Paul > > > >At 12:50 PM 5/12/99 -0500, you wrote: > >>Hi Paul, > >> > >>You misinterpreted what I said (or at least what I was trying to say). > >>Your referenced process to clear out a scrambler is correct, however, > >>what I stated was that all it takes is on the order of 2n bits to clear > >>it out, IF (an important if) you hit the scrambler with the correct > >>set of bits. In other words, if I know the PRESENT STATE of the scrambler > >>register bits, I can calculate a sequence of 2n bits which, when fed to the > >>scrambler WILL clear it out. In reality this may only require n bits, > >>but its been a couple years since I went through the excercise. > >> > >>So, for any given state of the scrambler there is always a set of n bits > >>which will clear it out. > >> > >>-Ed Grivna > >>Cypress Semiconductor > >> > >>> > >>> Ed: > >>> > >>> The 2n bits is wrong. To zero out a scrambler of order n, you need a > >>> pattern of (2**n - 1) bits. For instance, lets consider the seventh-order > >>> frame synchronized scrambler that is being used by SONET. The > pseudo-random > >>> sequence generated by the scrambler repeats itself every (2**7 - 1 = 127) > >>> bit periods. Since the pseudo-random output of the seventh register is > >>> XORed with the payload data, a user could transmit a pattern that > >>> continuously repeats the 127-bit pattern from the seventh register of the > >>> SONET scrambler. When the pattern from the seventh register is aligned > with > >>> the 127-bit pattern from the malicious user, the line will see an all > zeros > >>> pattern. > >>> > >>> So, to zero out the scrambler, the user > >>> 1- must know the order of the scrambler and its polynomial > >>> 2- must have access to the whole payload envelop > >>> 3- must use a pattern of (2**n - 1) bits generated by the polynomial > >>> 4- must repeat its pattern enough until it gets in phase with the output > >>> of the scrambler > >>> > >>> Paul > >>> > >>> At 07:06 AM 5/11/99 -0500, Ed Grivna wrote: > >>> > > >>> >> > >>> >> Mick: > >>> >> > >>> >> 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. > >>> >> > >>> >> Paul > >>> > > >>> >The problem is we are not dealing with randomized data. With reference > >>> >to a "properly designed scrambler," I can guarantee you that given > >>> >any scrambler based on a polynomial of degree N, you can zero it out > with > >>> >the correct string of around 2N bits. This is not boasting or > >>> grandstanding, > >>> >this is mathmatical fact. The SMPTE scrambler polynomial has a high > order > >>> >term of x^9, and it can be cleared with two characters of data. > >>> > > >>> >This doesn't say that scrambling can't be used. But it does mean that > >>> >a long polynomial needs to be employed to reduce (not remove) the > >>> >probability of zeroing out the scrambler. The longer the polynomial, > the > >>> >greater the latency of encode and decode, and the longer to re-sync if > >>> >it gets confused by bad data. Also, the longer the polynomial, the > greater > >>> >the error propagation; i.e., a one bit error in the serial stream will > mess > >>> >up more characters before its effects have propagated out of the > descrambler. > >>> > > >>> >The basic SONET polynomial has a high order term of only X^7, while > the ATM > >>> >srambler is X^43+1. The SONET scrambler can be cleared quite easily, > while > >>> >the ATM scrambler is quite difficult to clear. The protocol overheads in > >>> >these interfaces contain data that will keep the scrambler seeded, it is > >>> >the associated data field that can clear it out. > >>> > > >>> >Then you have the issue with the lack of special characters. With > respect > >>> >to the 802.3 signal stream, yes scrambling has been used before, but > at the > >>> >physical layer there has always been a mechanism to indicate non-data > >>> >signalling; i.e., a five level code where four levels are used for data > >>> >and the fifth is for signalling. > >>> > > >>> >This is difficult in an NRZ stream unless you change the stream from > >>> >character based to add an overhead bit every so many characters. The > >>> >telcos use this ALL the time. In a T3 system they add 1 bit out of > >>> >every 170 for synchronization and framing. > >>> > > >>> >Regards, > >>> > > >>> >Ed Grivna > >>> >Cypress Semiconductor > >>> > > >>> >> > >>> >> 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 > >>> >> >around. > >>> >> >Any statistical argument has to very carefully assess assumptions > as to > >>> >> >distribution and independence of variables. > >>> >> > > >>> >> >Mick > >>> >> > > >>> >> > > >>> >> > > >>> > > >>> > > >> > >>

**References**:**RE: WWDM vs. 10Gb/s serial***From:*Paul Bottorff

- Prev by Date:
**RE: Some Gigabit Ethernet history -- why are the links so overdesigned?** - Next by Date:
**Provocative KISSES: The case for Serial Ethernet etc.** - Prev by thread:
**RE: WWDM vs. 10Gb/s serial** - Next by thread:
**Re[2]: 1310nm vs. 1550nm -> Eye Safety + Attenuation** - Index(es):