[SI-LIST] Re: Do you really ship products at BER 10e-xx ?
- From: steve weir <weirsi@xxxxxxxxxx>
- To: <art_porter@xxxxxxxxxxx>, <hmurray@xxxxxxxxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
- Date: Wed, 13 Apr 2005 13:55:14 -0700
Art, a point of yours that I really agree with is that it can be far more
economical to attain system level message reliability with higher layer
processing, than to obsess on getting insanely low raw link error
rates. Older schemes like SONET do not retransmit and do not provide FEC
for payloads. But that doesn't stop any application from doing so above
the raw transport. For its trivial simplicity yet still relatively low B/W
and logic overhead, I like SONETs flag / pointer redundancy, and wish that
had been carried into CEP / PWE3.
Steve
At 02:21 PM 4/13/2005 -0600, art_porter@xxxxxxxxxxx wrote:
>Since most if not all real-world systems include some sort of error
>correction (or, more frequently, error detection and re-transmission
>facilities), the cost of errors in transmission is simply time for error
>detection and re-transmission. This cost goes in the budget along with the
>cost of overhead, system performance monitoring, services, etc. This also
>affects overall performance over time (how many bits per week can the
>system deliver error-free?). In the case of systems with
>ultra-high-reliability requirements, the cost may be reflected in the
>amount of reduncancy required.
>
>I would take issue with the statement "no errors for healthy links," or at
>least with the implied interpretation of that statement in this context.
>What the PacBell engineer probably meant was "The overall system -
>including error detection, redundancy, etc. - delivers messages
>consistently without errors." Not that any one link in the system is ever
>error-free.
>
>The time cost of errors is significantly affected by latency. How long
>does it take for transmission, reception, error detection, retransmit
>request back to transmitter, retransmission, second reception, second
>error detection?
>
>Engineers want to be able confidently to predict the overall operational
>parameters, performance, and operating costs of their systems, and to do
>this they need statistically valid methods to estimate (extrapolate)
>reliability of each individual component or subsystem. That was the thrust
>of the effort of the T11 MJSQ committee, for example, in developing a
>jitter taxonomy. Given the nature of the normal distribution, it doesn't
>take a very large standard deviation to have a bit error rate exceed 10E-12.
>
>Art Porter
>
>-----Original Message-----
>From: si-list-bounce@xxxxxxxxxxxxx
>[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of steve weir
>Sent: Wednesday, April 13, 2005 2:23 AM
>To: hmurray@xxxxxxxxxxxxxxx; si-list@xxxxxxxxxxxxx
>Cc: hmurray@xxxxxxxxxxxxxxx
>Subject: [SI-LIST] Re: Do you really ship products at BER 10e-xx ?
>
>
>At 11:40 PM 4/12/2005 -0700, Hal Murray wrote:
>
> > > Do you really let a machine runs at say BER 10e-12 and say "ah ha, it
> > > only fails once a day and let's ship it" ? Is BER really meant for
> > > IEEE spec committees and not for real engineers who actually have to
> > > ship a product ?
> >
> >I agree that the only number that makes sense is 0. The usual problem is
> >that it's next to impossible to measure the actual error rate. Years ago
> >(10?) I talked to a senior maintenance wizard for PacBell. He confirmed no
> >errors for healthy links. It would be interesting to see some recent data
> >from in-service links.
> >
> >In the long distance fiber world, the link budget normally allows for a few
> >splices to be added over the life of the link and for the transmit laser to
> >get weaker over time.
> >
> >Somebody taught me a neat trick. The BER on fibers is easily computed from
> >SNR. Its exponential (like metastability). The trick for measuring error
> >rates is to insert some attenuation in the link so that you get enough
> errors
> >to measure. Then compute the expected error rate without the attenuation.
>
>
>Shannon lives!!!
>
>
>
> > > Any real system, with a real transmitter generating some very small
> > > finite amount of Random Jitter, RJ, cannot operate "error free". It
> > > is an issue of probabilities. By definition, RJ is unbounded,
> > > therefore there is always some probability of a failure.
> >
> >The same is true for metastability, yet we manage to build acceptably
> >reliable systems.
> >
> >(Actually, with that line of reasoning, I think a clock with RJ will also
> >break setup/hold times on normal digital logic, but let's not go there now.)
>
>
>But then that really is the topic. At some point, "enough" RJ will occur
>whether the jitter is due to oscillator variation, or signal pull-in /
>push-out. If we take a triangle wave based multivibrator and sum either
>the reference level or the ramp with a noise source, as soon as the noise
>amplitude is high enough, we can truncate one phase to almost zero. It
>thankfully shouldn't happen very often, but as Tom points out, someday it
>will likely happen.
>
>When I was learning this curious trade I was initially annoyed by the
>notion that digital circuits don't always work. But, I think it is
>actually a crucial concept. We can reduce the probability of a functional
>error to very low levels by a number of measures but it isn't going to
>zero. Just ask the FPGA guys about the potential consequences of SEIs
>popping a configuration bit. Now there is a costly bit error.
>
>
> >Is RJ on a link really random? (Does that mean Gaussian in this context?)
> >Assuming it is, can we compute the probability of errors on a
> link? (Perhaps
> >based on some lab tests like are used to predict metastability.) Is a link
> >good enough if the estimated MTBF is beyond the age of the universe?
> >
>Well I the problem is the MTBF concept. MTBF only predicts the average
>failure rate over time for a population. I think some people confuse that
>with some errant notion of: "It will be at least the MTBF before any error
>occurs".
>
>If the cost of a single error is high then it is worthwhile to drive MTBF
>up, reducing the likelihood, but never eliminating it. Given external
>disturbances as you do below, it is likely that few links benefit
>economically from extraordinary measures to drive random effects to nearly
>zero.
>
>
> > > We're being pressed to measure bit error rates to 10E-15 and at those
> > > rates you start worrying more about nearby lighting strikes and
> > > power-outages rather than the RMS noise on a rail.
> >
> >Don't forget air conditioning and operator error and software bugs.
> >
> >Would it help to insert some attenuation when testing a copper link? Or
> >perhaps, deliberately shift the receive clock?
> >
> >Would it be useful to build some optional attenuation into one end or the
> >other to make it easier to test copper links? I'm thinking of into the chip
> >selected with a CSR bit as compared to on the board between the
> connector and
> >the chip. Same for optional clock shifting.
> >
> >Isn't that sort of logic included on some RAM interfaces? Has anybody
> >deliberately de-tuned the normal setup to look for errors?
> >
> >
> >Do the transistors in drivers/receivers get wounded rather than killed with
> >sub-fatal ESD events? How much of a problem is this?
>
>ESD induced stress does wound parts degrading performance. Doug Smith has
>plenty of examples.
>
>
>
>
>
> >--
> >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.
> >
> >
> >
> >------------------------------------------------------------------
> >To unsubscribe from si-list:
> >si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
> >
> >or to administer your membership from a web page, go to:
> >//www.freelists.org/webpage/si-list
> >
> >For help:
> >si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
> >
> >List FAQ wiki page is located at:
> > http://si-list.org/wiki/wiki.pl?Si-List_FAQ
> >
> >List technical documents are available at:
> > http://www.si-list.org
> >
> >List archives are viewable at:
> > //www.freelists.org/archives/si-list
> >or at our remote archives:
> > http://groups.yahoo.com/group/si-list/messages
> >Old (prior to June 6, 2001) list archives are viewable at:
> > http://www.qsl.net/wb6tpu
> >
>
>
>------------------------------------------------------------------
>To unsubscribe from si-list:
>si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
>
>or to administer your membership from a web page, go to:
>//www.freelists.org/webpage/si-list
>
>For help:
>si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>
>List FAQ wiki page is located at:
> http://si-list.org/wiki/wiki.pl?Si-List_FAQ
>
>List technical documents are available at:
> http://www.si-list.org
>
>List archives are viewable at:
> //www.freelists.org/archives/si-list
>or at our remote archives:
> http://groups.yahoo.com/group/si-list/messages
>Old (prior to June 6, 2001) list archives are viewable at:
> http://www.qsl.net/wb6tpu
>
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field
or to administer your membership from a web page, go to:
//www.freelists.org/webpage/si-list
For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
List FAQ wiki page is located at:
http://si-list.org/wiki/wiki.pl?Si-List_FAQ
List technical documents are available at:
http://www.si-list.org
List archives are viewable at:
//www.freelists.org/archives/si-list
or at our remote archives:
http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
http://www.qsl.net/wb6tpu
Other related posts:
