Hacker News Reader

Comment by jedberg | Hacker News Reader

How do they generate data at that rate to transmit? I assume it's synthetic data and probably duplicated a lot? But how do they generate it and receive it to count it?

View on HN

> How do they generate data at that rate to transmit?

In the lab, the most common scenario is to have a pseudo-random bit sequence (PRBS), and usually the sequence is 2^31-1 bits long. This makes both the generation (on the transmit side) and error-rate detection (on the receive side) reasonably straightforward, although it can be tricky to read out every one of the receive channels to check the bit-error rate (BER).

Here's typical PRBS BER equipment: https://www.anritsu.com/en-us/test-measurement/products/mp19...

Spoiler alert: The test equipment isn't cheap.

Edit: Probably should mention- PRBS from a linear-feedback shift register is used, because in a PRBS of 2^N-1 you are guaranteed every permutation of N bits long, except for N x zeroes in a row. This measures the wideband system, so if there are spurious resonances in the wide pass band, errors will result.

As someone who's become a bit of a test equipment nerd, that is _very_ neat.

Actually, we tend not to use PRBSs anymore for these sort of experiments, instead you use a randomly generated symbol/bit sequence which fits into the memory of the DAC. Similarly you don't use a BERT anymore but instead use a Realtime oscilloscope (even more expensive than the BERTs) and do offline digital signal processing (in real systems this is done by very expensive asics). PRBSs and BERTs are still uses in so called datacom experiments where latency is often an issue and only very lightweight FEC is used, so one wants to measure down to error rates of 10e-9 unlike coherent systems.

I find that interesting, and am curious:

> instead you use a randomly generated symbol/bit sequence which fits into the memory of the DAC.

How do you guarantee coverage of the entire spectrum? As I mentioned above, PRBS(N) has every bit sequence possible for N bits, which would expose any drop outs or resonances.

> so one wants to measure down to error rates of 10e-9 unlike coherent systems.

Back in the day, for OC-768 (40 Gbps/43 Gbps with FEC) equipment was measured to 10e-12. Has that relaxed? [IIRC, to gain 95% confidence that BER is 10e-9, you had to measure 10e10 bits. Similarly, for 95% confidence of BER 10e-12 you had to measure 10e13 bits. It's been a while though.]

Very late reply so you might not see it. Modern systems use coherent (phase&amplitude and polarisation, typically QAM formats), together with relatively high overhead (~20%) FEC. The consequence is that for demonstration experiments you do offline processing, which significantly constrains how many bits you can measure (good experiments measure a few million per measurement point). So what people do is measure to the FEC threshold (10e-2) and assume the FEC works (usually a valid assumption). Sometimes people implement the FEC and show error free operation to 10e-6 or so. Also we use Generalized Mutual Information as a more accurate measure of the information content (it essentially measures how much information can be transmitted given a bitwise coding FEC).

In other experiments people show FEC implementations running on banks of FPGAs to show that we actually get down to BER 10e-12, but these take weeks on large number of high end FPGAs.

The two other comments gave very good general answers, but I happen to have worked on this specific project, so I can give some very specific details (as far as my memory goes.)

Lab testing of this scale of transmission involves a bit of “educated simplification”. We had some hundreds of wavelength channels, 37 fiber cores and two polarizations to fill with data. That is not realistic to actually do within our budget, so instead e split the system into components where there is no interference. For example, if there is different data on all neighboring cores compared to the core-under-test, then we dare to assume that the interference is random, without considering neighbors’ neighbor etc.

This reduces our perspective to a single channel under test with known data and then at least one other channel which is just there as “noise” for the other channels. The goal is to make the channel-under-test have a realistic “background noise” from neighboring interference. This secondary signal is sometimes a time-delayed version, sometimes a completely independent (but real) data signal.

This left us with a single signal of 32 GBd (giga symbols / s). This is doable on high-performance signal generators and samplers.

Ah ok so you just extrapolate the capacity of the pipe based on that, you don't actually generate petabytes of data. That makes a lot of sense, thanks!

I should clarify that we did measure every channel (polarization, wavelength and fiber core) individually. It would not be fair if we just measured one and multiplied ;)

(And yes, that took forever. A shout out to A. A. Jørgensen and D. Kong for their endurance in that.)

That's a good question! I assume that their test run is very short, like maybe a nanosecond. A petabit is 10^15 bits, which means they only needed to generate 10^6 bits (a megabit) for such a run. But even then, I'd be curious to know how you feed a laser 10^6 bits of configuration data in 10^-9 seconds! Definitely a paper I'd like to read.

So the way you do these experiments that at the transmitter you use an arbitrary waveform generator with ~4 DAC channels which let you modulate a single wavelength channel in IQ and two polarizations (4 dimensions). These devices have typically a memory of around 500k samples and rates of up to 120 GS/s (newest one actually has 256 GS/s Google keysight AWG if you are interested). So you generate a sequence of ~120k symbols (depending on symbolrate/oversampling) with 12 bit/per symbol (assuming 64 QAM). That sequence repeats over and over. You then use the multiplexing/emulation techniques described in other posts to emulate the other channels. This is essentially due to limitations of the measurement equipment. You can't just convert a random incoming bitstream into analogue symbols (with FEC coding) in realtime.

In a deployed system this would be done by specific Asics that take millions to develop and are comparatively inflexible. Thus if you want to test/research methods you use the above mentioned equipment which gives much more flexibility.

Reply on news.ycombinator.com