Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_B400G_OPTX] Fw: P802.3dj SMF topics discussion group about Jitter, TDECQ, Error floors

In informal discussions with 802.3 optics excerpts about our current specifications, I made the analogy of a restaurant chef faithfully following recipes of menu items, but never actually tasting food before serving it to customers.

We should consider adding a set of BER tests (ex. long term, burst, possibly frame) of TX into a compliant RX. This is not a reference RX, only a RX that meets 802.3 specs. To be useful, the measurement RX has to be fully verified for compliance, most importantly SECQ, not just what's typically done in manufacturing. We can decide if this test is just BtB, or also over fiber(s). 

Chris

From: Chris Cole <chris.cole@xxxxxxxxxxxx>
Sent: Tuesday, December 3, 2024 11:44 AM
To: STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx <STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx>
Subject: [802.3_B400G_OPTX] Fw: P802.3dj SMF topics discussion group about Jitter, TDECQ, Error floors
 
The below informal thread discusses Jitter, TDECQ, error floors and alternate measurements which may be of interest to the broader 802.3dj optics community. 

Chris

From: Chris Cole
Sent: Sunday, December 1, 2024 9:02 AM
Subject: Re: P802.3dj SMF topics discussion group
 
We understand the interoperability limitations of reference receivers, which led the IEEE to move away from ITU-T style specifications. However, hopefully we should also understand the reasons waterfall curves are the single most important measurement in communications. Shannon has something to say about that. 

The 802.3 specs we have in place provide guardrails against most reference receiver corner cases, which did not exist when horror stories got seared into our collective consciousness. Together with equalizers, they are good enough that we don't even need an additional reference receiver definition. DUT Tx to DUT Rx sweeps (BtB and over fiber) will smoke out what we are worried about, like Tx low frequency jitter. The problem was identified through BER, so the solution is staring us in the face. We spec a floor and ignore the absolute sensitivity. We get the added benefit of a more accurate D than in TDECQ.

Chris

From: Ali Ghiasi
Sent: Sunday, December 1, 2024 3:09 PM
Subject: Re: P802.3dj SMF topics discussion group
 
Hello Adee,

Jitter in the context of J3/J4U TDECQ using SSPRQ actually does a better job capturing low frequency jitter down to ~1.6 MHz.  The key thing is to operate the module in mission mode otherwise no jitter will propagate through.

If we need to go beyond what TDECQ with SSPRQ can capture then we can use the well established SONET style jitter generation as we as explored in the following presentation from Me Karl and Pavel:
preview.png

We have no experience with PAM4 transmitter and wide band jitter generation and will take some time to develop reasonable limits.  Before we add whole new test we need to better understand cost-value, and how much do we gain after specifying TDECQ test mission mode.
The opinion of the above presentation authors is that even if we added jitter generation, we could not reasonably discriminate between good and marginal transmitters.  The question for authors ofhttps://www.oiforum.com/bin/c5i?mid=4&rid=5&gid=0&k1=54499
is why receiver SNR=22.47 dB but BER is only 3E-6, unless we understand the test condition better not sure we will be able to address the underlaying issue!

Thanks,

Ali Ghiasi
Ghiasi Quantum LLC
Office (408)352-5346

On Dec 1, 2024, at 10:46 AM, Adee Ran wrote:

It seems to me that a lot of intellect in this thread goes towards improving TDECQ to address concerns like noise coloring. I am sure a lot could be studied and maybe eventually some improvements can be adopted.
 
However, the specific concern we raised, following Marco’s experiments and prior observations, is jitter. It is a well-known effect of transmitters (not due to the optics but rather to the electronics that drives them) that has been observed to cause FEC degradations. I presented a summary of Marco’s work (originally presented in OIF) in the optical ad hoc – see https://www.ieee802.org/3/dj/public/adhoc/optics/0824_OPTX/ran_3dj_optx_01_240829.pdf [ieee802.org].
 
Jitter is easy to measure with existing equipment and adding it to the optical specs would be the low hanging fruit, sound engineering solution to the apparent problem. No need to redefine TDECQ for that.
 
I intend to revisit this topic during WGB.
 
</Adee>

From: Hossein Shakiba
Sent: Thursday, November 28, 2024 1:01 PM

Subject: RE: P802.3dj SMF topics discussion group
 

Hi Bill,

 

For the MLSE, noise coloring causes the “sequence of samples” to be correlated and the method calculated the sequence noise statistics with consideration of the correlation through the sequence. Here I guess we are not facing a “sequence of samples” in time.

 

Regards,

Hossein

 


From: Bill Kirkland
Sent: November 28, 2024 3:52 PM
Subject: RE: P802.3dj SMF topics discussion group

 

I was “hoping” they could borrow on how you dealt with impact of colored noise on the stats, SER/ COM.
Don’t think any one is contemplating mlse for TDECQ 😊.

 


From: Hossein Shakiba
Sent: Thursday, November 28, 2024 3:45 PM
Subject: RE: P802.3dj SMF topics discussion group

 

Hi Bill,

 

Thanks for including me. I suppose If the TDECQ reference receiver will require an MLSE (as far as I know, so far it doesn’t), the statistics (PDFs, CDFs, …) can be used for MLSE performance evaluation, similar to COM.

 

Regards,

Hossein

 

 

From: Bill Kirkland 
Sent: November 27, 2024 3:33 PM
Subject: RE: P802.3dj SMF topics discussion group

 

Added Hossein because of my comments below.

 

1st, I am not following this in depth, but it strikes me that folks are trying to take the TDECQ measurement and make it do things it wasn’t intended to do.

 

I would suggest that enabling a TDECQ signal capture, could trigger other measurements that are not captured by the TDECQ spec itself.

E.g. In radio we have an EVM measurement, but there are a lot of useful other diagnostic measurements that come about from the EVM measurement,
  e.g. EVM across OFDM carriers, EVM due to phase noise, ….

 


TDECQ gathers the statistics of the signal via the histograms hence it is looking at PDF’s and CDF’s.
These statistics ignore the correlation present within the signal. They may or may not capture the impact of the correlation, e.g. low frequency jitter depending on how long the measurement is run for.

Nor was TDECQ intended to anticipate the decoded error performance. Rather it is more like the COM Tool.
Traditionally both look at probability of single error events, but not how the error events are related/correlated.

Both TDECQ and COM Tool look at PDFs/CDF’s, i.e statistics.

 

There is a reason Noise is described by 4 letters, AWGN, A-additive, W-white (uncorrelated), G-Gaussian (probability), N – Noise.
All of these letters are independent. I point out, White Noise does nothing to describe the pdf of the Noise.

 

I am wondering if the data collected in TDECQ, could be used to generate the statistics that Hossein has used to predict MLSD and DFE performance.
Since I haven’t understood Hosseins work, I may be totally off base here.

 

Having said that I don’t think TDECQ is the appropriate “metric” that doesn’t mean that the data TDECQ collects couldn’t be processed to determine another metric .

Of course the device being measured, should be set up appropriately (Ali’s presentation).
Measurement patterns (SSPRQ) and “duration/capture” length should be appropriate. (I think the original TDECQ spec implied the capture of 1 SSPRQ pattern could be used).

 

Thanks to all those looking into this!!

 

Bk

 

From: Mike Dudek
Sent: Wednesday, November 27, 2024 1:13 PM
Subject: RE: P802.3dj SMF topics discussion group

 

I agree with what Adee is saying except that I would say that TDECQ covers the effect of jitter on the average bit error ratio.   I agree that it does not cover the degradation in post FEC performance with good average bit error ratio that can be caused by low frequency jitter.   However  J4u also doesn’t discriminate between high frequency jitter and low frequency jitter so I think evidence that a J4u spec would help without failing good transmitters should we provided before we add an additional specification requirement (and possible false fail probability) to the standard.   A more discriminating test may be required.  

 

Also I would point out that a similar problem may exist with low frequency amplitude noise and we may need to add a specification for that.   

 

From: Adee Ran
Sent: Wednesday, November 27, 2024 6:53 AM
Subject: RE: P802.3dj SMF topics discussion group

 

Hi,

 

I didn’t attend the call with Ali’s presentation, but I’d like to express my support for this direction.

 

I would add that TDECQ requirements need to be met by a PHY (a module in a host) and not just by the PMD in isolation. The test with stressed input to the module’s AUI is relevant for modules tested independently, but it cannot be a requirement for the PHY (the host’s signal is what it is – it does not necessarily stress the module).

We did not have explicit distinction between PHY requirements and PMD requirements in past PMD clauses, but we should consider new content that clarifies the difference.

 

I would also note that this proposal still doesn't cover low-frequency jitter which is not necessarily caught by TDECQ and can cause correlated errors. I still intend to suggest adding a J4u specification for the IMDD PMDs, as this is a straightforward measurement that can improve the quality of the standard.

 

</Adee>

 

From: Mark Nowell 
Sent: Wednesday, November 27, 2024 4:15 PM
Subject: Re: P802.3dj SMF topics discussion group

 

Hi everyone,

 

Attached is the presentation Ali put together.  General sense of the discussion was that the intent of this proposal is supported but we need to do some work to figure out how to implement this appropriately into the document which is intended to be independent of implementation.

 

Also attached is a copy of the list of data that was requested about a year ago from the TF.  I’d like to re-make this request at the upcoming ad hoc call on 12/19.  I’d appreciate any feedback on what might change/modify from the previous list.

 

Thanks,
Mark

To unsubscribe from the STDS-802-3-B400G-OPTX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-OPTX&A=1

To unsubscribe from the STDS-802-3-B400G-OPTX list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G-OPTX&A=1