[SI-LIST] Re: Do you really ship products at BER 10e-xx ?
- From: <art_porter@xxxxxxxxxxx>
- To: <weirsi@xxxxxxxxxx>, <hmurray@xxxxxxxxxxxxxxx>, <si-list@xxxxxxxxxxxxx>
- Date: Wed, 13 Apr 2005 14:21:09 -0600
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. =20
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. =20
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?=20
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. =20
Art Porter =20
-----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 ?=20
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=20
whether the jitter is due to oscillator variation, or signal pull-in /=20
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=20
amplitude is high enough, we can truncate one phase to almost zero. It=20
thankfully shouldn't happen very often, but as Tom points out, someday =
it=20
will likely happen.
When I was learning this curious trade I was initially annoyed by the=20
notion that digital circuits don't always work. But, I think it is=20
actually a crucial concept. We can reduce the probability of a =
functional=20
error to very low levels by a number of measures but it isn't going to=20
zero. Just ask the FPGA guys about the potential consequences of SEIs=20
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=20
failure rate over time for a population. I think some people confuse =
that=20
with some errant notion of: "It will be at least the MTBF before any =
error=20
occurs".
If the cost of a single error is high then it is worthwhile to drive =
MTBF=20
up, reducing the likelihood, but never eliminating it. Given external=20
disturbances as you do below, it is likely that few links benefit=20
economically from extraordinary measures to drive random effects to =
nearly=20
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=20
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: =20
//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
=20
------------------------------------------------------------------
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:
