Hacker News new | ask | show | jobs
by willis936 2200 days ago
Impressive stuff. I think the BER is appallingly high. Current applications want pre-FEC BER on the order of 10^-12, not 10^-2. TANSTAAFL.
5 comments

Howdy, I design optical integrated circuits for coherent communication. mmmBacon is correct. See here[0] or [1] for examples of the types of forward error correction used in coherent links. Pre-FEC bit error rate thresholds of 1e-3 or 2e-2 for <1e-15 post-FEC errors are fairly standard.

[0] https://www.cablelabs.com/forward-error-correction-fec-a-pri... [1] PDF warning: https://www.infinera.com/wp-content/uploads/Soft-Decision-Fo...

Modern optical systems require strong FEC and it’s not uncommon for systems to have pre-FEC BER 1e-3. The FEC gain is high enough to guarantee 1e-12 to 1e-15 post-FEC. Due to FEC it’s not necessary or desirable to have pre-FEC BERs of 1e-12.
> and it’s not uncommon for systems to have pre-FEC BER 1e-3.

Old guy here: I'm wondering when that changed. Early OC-768 requirements were 10^-12 BER preFEC (e: at least in short-haul), which was down from 10^-9 for OC-192.

People realised that you maximize the throughput of the raw medium if you push it hard enough it has a high error rate, and then correct those errors.

Error correction tech has reached information theory perfection (if you ignore latency), so it always makes sense to use as much of it as possible. In the future I wouldn't be surprised to see bit error rates pretty close to 1:1, and massive amounts of FEC.

> People realised that you maximize the throughput of the raw medium if you push it hard enough it has a high error rate

When?

FEC has been used in optical systems for decades. The undersea fiber guys have been using it in production at least since the 90s, for example. So I'm a little amazed that decades went by before someone noticed that you can throw BER out the window for the components and drivers to improve the overall system BER.

From systems pre-error-correction... Think RS-232 serial for example... No error correction there, so people typically don't push hardware too close to the limits of bit rates because every bit error will cause some breakage. Even today, a lot of modern devices talk with RS232-like protocols, and none of them have even parity bits - it's just assumed error rates are so low as to be zero across the useful life of the product.
It probably used to be cheaper to use high-quality optical components until Moore's Law brought down the cost of FEC enough.
For readers less familiar with the topic:

- BER = Bit Error Rate

- FEC = Forward Error Correction

- TANSTAAFL = https://en.wikipedia.org/wiki/There_ain%27t_no_such_thing_as...

For them like me who don't know https://en.wikipedia.org/wiki/Forward_error_correction as I didn't know what the 'forward' part meant.

It seems be error correction add to the sending stream to 'mend' broken data, vs error correction by the receiver detecting an error and requesting a re-send.

And just to elaborate a bit further: Forward error correction is the coding (as in information coding) principle of how to enable error correction. The error correction still happens at the receiving end and it is aided by the redundancy introduced by FEC.
I can't find anything in the paper, but maybe it is possible to be not quite so greedy with the bandwidth thereby reducing the BER to acceptable levels.

On the other hand, high BER doesn't preclude usefulness, one just would need different FEC to deal with that. Maybe a pratical implementation with a robust FEC will still come ahead in useful throughput.

10^-12 before FEC strikes me as outlandishly low.

Why would applications even care about the BER before FEC?.

FEC does not perform miracles. It only trades off some throughput for a few orders of magnitude in BER. FEC can also be defeated by common types of distortions. If you get a spike of alien crosstalk then you aren’t going to just get one bit error, so you really do need that high fidelity connection if you don’t want your link to shit the bed in the real world.
That quoted number might be 'before non-forward error correction', ie. Before resending the data, which involves an extra roundtrip and degrades service.