On Fri, 09 Jun 2006 04:54:30 GMT, "Maxim S. Shatskih"
<maxim@storagecraft.com> wrote:

>> Actually with 10mb/s Ethernet and USB (all speeds) there is no carrier
>> on the wire when actual data is not begin transmitted.
>
>Same as with serial UART.
>
>>Clock recovery
>> starts at an arbitraty point with every packet.
>
>USB packets have a preamble to synchronize the PLLs. IIRC Ethernet too.

There are no clock-recovery PLLs in USB. FS/LS is specifically
designed to be implemented by a 4x DLL. One can implement 10BT without
a PLL too.

Hal Murray wrote:
> >> Much lower than that would be a serious problem.  Much
> >> higher would be hard to measure.
> >Yep - until you start feeding PRBS test streams into the scrambler,
> >which can make your equipment look less reliable than it would be
> >against a real-world stream.
>
> I'm missing something.  Why is a PRBS test stream going to make
errors?
>
> To make a long string of 0s, you have to send something that
> matches the pattern in the scrambler register.  That pattern
> is supposed to be random - hard to guess and hard to hit by
> sending malicious data.
>
> Is there a trick or quirk I don't know about?

Howdy Hal,

   I did a poor job of editing your original response, and an even
poorer job of explaining mine - sorry!  I was actually trying to
provide an example in response to your "much lower would be a serious
problem" statement.  We've chased phantom bugs in our equipment before
where a weekend long test would take a data hit.  It was eventually
tracked down to a device that effectively had a very short run-length
tolerance.  It wasn't a CDR, but the result was the same.  We've also
had a (different) vendor tell us that we had to order the STS's within
our scrambled data stream in a certain way, or downstream devices may
lose CDR lock.

BTW, the 75 bit CID number for the V2Pro CDR can be found here:

http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=15035
http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=15049
http://xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=15055

   Marc

>Yep - until you start feeding PRBS test streams into the scrambler,
>which can make your equipment look less reliable than it would be
>against a real-world stream.

I'm missing something.  Why is a PRBS test stream going to make errors?

To make a long string of 0s, you have to send something that
matches the pattern in the scrambler register.  That pattern
is supposed to be random - hard to guess and hard to hit by
sending malicious data.

Is there a trick or quirk I don't know about?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
> >A CID (consecutive identical digits) of 50 bits will cover most
> >real-world cases of scrambled SONET traffic, but I'd personally want
a
> >CDR with noticably more staying power than that.
>
> 2**50 is 10**15  With a gigabit/sec link, that would be a glitch
> every 10**6 seconds or roughtly 10 days.  Note that we are talking
> clock-slip which is much worse than a simple bit error.
> Adjust for your link speed.
>
> I typed in 50 without much thinking.  Looks like I got in the right
> ballpark.

Yes, you did.

> Much lower than that would be a serious problem.  Much
> higher would be hard to measure.

Yep - until you start feeding PRBS test streams into the scrambler,
which can make your equipment look less reliable than it would be
against a real-world stream.

> I think I remember 70 from years ago on OC-3.  That would be
> another factor of 10**6 which would push the problem well
> beyond the lifetime of any gear I've ever worked with.
>
> What are current specs/reality for SONET links?  Are there any
> interesting alternatives to SONET for long links?

I don't think there is an absolute minimum requirement, but a commonly
accepted number is 72 digits - so your memory is quite good.  Modern
CDR's tend to be able to handle even more digits than that, but as you
said, the probability starts getting so low that it is well beyond the
lifespan of just about anything (humans, electricty, copper wire, etc).
 Somewhere I got it that the V2Pro MGT can handle over 75 CID (to try
to insert at least one FPGA related item to this post).

As for long haul links, if you want protection, SONET is still the main
choice.  I think that RPR is trying to make in-roads, but has been slow
out of the gate and from what I've heard third hand, is slow to be
adopted by the carriers.  I believe a third alternative is protected
DWDM (not as intelligent as SONET or RPR, but that means maintenance is
considerably less expensive).  There may be others I can't recall at
the moment.

Have fun,

   Marc

>A CID (consecutive identical digits) of 50 bits will cover most
>real-world cases of scrambled SONET traffic, but I'd personally want a
>CDR with noticably more staying power than that.

2**50 is 10**15  With a gigabit/sec link, that would be a glitch
every 10**6 seconds or roughtly 10 days.  Note that we are talking
clock-slip which is much worse than a simple bit error.
Adjust for your link speed.

I typed in 50 without much thinking.  Looks like I got in the right
ballpark.  Much lower than that would be a serious problem.  Much
higher would be hard to measure.

I think I remember 70 from years ago on OC-3.  That would be
another factor of 10**6 which would push the problem well
beyond the lifetime of any gear I've ever worked with.

What are current specs/reality for SONET links?  Are there any
interesting alternatives to SONET for long links?

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Hal Murray wrote:
> >Thanks for that but I already knew it existed: I wasn't trying to
pretend I
> >had invented something.  But my original question was why isn't it
more
> >widely used?
>
> It is widely used - at least if you are generous on what "it" is.

Like if "it" can be equal to Ethernet? :-)

> Manchester is very easy to implement with good DC ballancing but
> only 50% efficient.  4B/5B (FDDI) is 80% efficient but not quite
> ballanced in some cases.  8B/10B is ballanced but more complicated
> to implement.

Just to make this this discussion complete, with 64B/65B and 64B/66B
there are finally encoding schemes with efficiencies worth being proud
of.

[...]
> For an alternative approach, google for scrambling as used on SONET.
> The general idea is to start with a good clock recovery circuit (say
> 50 bits without any transitions) and then randomize the data stream
> by XORing it with a random pattern so you still have transitions if
> the user sends all 0s or whatever the nasty pattern is.

A CID (consecutive identical digits) of 50 bits will cover most
real-world cases of scrambled SONET traffic, but I'd personally want a
CDR with noticably more staying power than that.

Have fun,

   Marc

>Thanks for that but I already knew it existed: I wasn't trying to pretend I
>had invented something.  But my original question was why isn't it more 
>widely used?  

It is widely used - at least if you are generous on what "it" is.

There are two conflicting properties you want when transmitting data
over a link.  You need transitions in the data stream so the receiver
can do clock recovery.  But useless transitions reduce link bandwidth
efficiency.

Another goal is to make the data stream ballanced so you can run
it through a capicator or transformer.

Manchester is very easy to implement with good DC ballancing but
only 50% efficient.  4B/5B (FDDI) is 80% efficient but not quite
ballanced in some cases.  8B/10B is ballanced but more complicated
to implement.

Typical async RS-232 is 80% efficient and easy to implement as
long as the signal is clean (aka distance is short relative to
the bit rate).

If you have long links, the fiber/cable is the expensive part and
you are willing to work harder (pay more) on clock recovery to get
more bits through the pipe.  On the other hand, for something like
Ethernet or RS-232 with short links, you are generally willing to
trade link bandwidth (or distance) for simpler decoding procedures.

For an alternative approach, google for scrambling as used on SONET.
The general idea is to start with a good clock recovery circuit (say
50 bits without any transitions) and then randomize the data stream
by XORing it with a random pattern so you still have transitions if
the user sends all 0s or whatever the nasty pattern is.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

In article <423699e0$1@clear.net.nz>, Jim Granville wrote:
> Andrew Smallshaw wrote:
>> On a slightly different note, does anyone know why most serial protocols
>> use simple voltage levels to denote a logic 0 or 1?  I admit I'm no expert
>> but I recall from my A-level electronics an edge-triggered system where a
>> '0' would be (say) low-followed-by-high whereas a '1' would be
>> high-followed-by-low.  Yes, this means _at_least_ twice as many voltage 
>> transitions per bit but I would have thought that given its greater resilience
>> mismatched clocks or any stray capacitance it would be worth the trade off.
> 
>   This is used already, and is called Bi-Phase or Manchester encoding, 
> for the two phase variants of this Clock+Data Scheme.
> -jg

Thanks for that but I already knew it existed: I wasn't trying to pretend I
had invented something.  But my original question was why isn't it more 
widely used?  

Hmmm... Manchester encoding.  Is that another great thing my old University
came up with?  The battery on this laptop is about to expire so I've not got
time for a Google search now...

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

"Alexei A. Frounze" <alexfru@chat.ru> writes:
> If the noise happens to invert two of the middle samples... I think better
> would be to have more than 3 and less than 16 to drop the boundary effects
> and count on more samples. 8?

If your line is that noisy, you're unlikely to have good results no matter
how the sampling is done.  I've never seen a serial line have that much
trouble, except on a 150m run from a factory floor to a computer room
three floors above.  On that, the main problem was a difference in ground
potential, and the cure was to switch to a balanced EIA-422 line with
electrical isolation at one end (cheaper than going to fiber, which would
also have worked).

Eric

Andrew Smallshaw wrote:
> On a slightly different note, does anyone know why most serial protocols
> use simple voltage levels to denote a logic 0 or 1?  I admit I'm no expert
> but I recall from my A-level electronics an edge-triggered system where a
> '0' would be (say) low-followed-by-high whereas a '1' would be
> high-followed-by-low.  Yes, this means _at_least_ twice as many voltage 
> transitions per bit but I would have thought that given its greater resilience
> mismatched clocks or any stray capacitance it would be worth the trade off.

  This is used already, and is called Bi-Phase or Manchester encoding, 
for the two phase variants of this Clock+Data Scheme.
-jg