[SI-LIST] Re: Do you really ship products at BER 10e-xx ?
- From: Hal Murray <hmurray@xxxxxxxxxxxxxxx>
- To: si-list@xxxxxxxxxxxxx
- Date: Tue, 12 Apr 2005 23:40:52 -0700
> 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.
> 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.)
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?
> 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?
--
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
Other related posts:
