Re: [802.3_B400G_ELEC] Jitter profile for input test

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

You are listing Jrms (all) and rms/R03/f03 values. This isn’t what we now have in the draft where a new measurement method is used that removes amplitude noise. Would that make a difference?

If this is for Interference tolerance why is Sj being added. BUJ is what is suggested (however I suspect that BUJ will also create RMS jitter).

From: Hadrien Louchet <000048266f3548a2-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 14, 2025 1:57 AM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] Re: [802.3_B400G_ELEC] Jitter profile for input test

Hello Mike, Hello Adee, Thank you very much for your feedback. Adee, In principle, I agree with your following statement: However, having both J4u and JRMS at their limits practically requires that the jitter profile include both dual-Dirac

ZjQcmQRYFpfptBannerStart

Prioritize security for external emails:

Confirm sender and content safety before clicking links or opening attachments

Report Suspicious ‌

ZjQcmQRYFpfptBannerEnd

Hello Mike, Hello Adee,
Thank you very much for your feedback.

Adee,
In principle, I agree with your following statement:

However, having both J4u and JRMS at their limits practically requires that the jitter profile include both dual-Dirac and Gaussian components.

However, there is a caveat: SJ is not random, but does impact the rms jitter. In theory, 50mUI SJ leads to 18mUI Jrms. This is what we observe on our pattern generator, which has low intrinsic random jitter (<5mUI). As you can see from the table, it is possible to get close to the particle limits by injecting SJ only.

I also agree with you on
As a side note, the C2M test specifies having SJ, RJ, and BUJ;
However, I couldn’t find any explicit mention of it in IEEE 802.3dj 2.0.

Thank you,

Hadrien

From: Adee Ran (aran) <0000147b29386f6c-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Sunday, July 13, 2025 8:54 AM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G_ELEC] Jitter profile for input test

Hi Hadrien,

Thanks for highlighting this area.

As Mike noted, the interference tolerance test definitions for CR/KR receivers do not tell the user explicitly what jitter cocktail to use. However, having both J4u and JRMS at their limits practically requires that the jitter profile include both dual-Dirac and Gaussian components.

The procedure includes a translation of measured jitter values J4u/JRMS to the jitter model parameters A_DD and sigma_RJ – this may serve as a hint that both components should exist. Depending on the pattern generator, it is possible that both components need to be injected, but if the RJ floor is high then maybe only SJ needs to be injected, and vice versa. Test engineers understand that, and I think further guidance in the standard is not necessary.

The jitter tolerance test for CR/KR (179.9.5.4) does include specific values of SJ, essentially the same as the ones used for C2M stressed input test in Annex 120G (with one additional frequency point).

As a side note, the C2M test specifies having SJ, RJ, and BUJ; SJ values are given, but the combination of RJ and BUJ is left open. I have seen calibrated stressed eyes with different combinations, leading to possible ambiguity. I am not sure about the benefit of this requirement (I usually recommend using only SJ and RJ to reduce the ambiguity).

</Adee>

From: Mike Dudek <mdudek@xxxxxxxxxxx>
Sent: Saturday, July 12, 2025 12:39 AM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G_ELEC] Jitter profile for input test

I think it is reasonable to specify this. However I think the intent is that no SJ is deliberately injected. (It is deliberately injected for the Jitter Tolerance test). If SJ isn’t being adjusted then adjusting BUJ and RJ will have a unique solution to achieve the J4U03 and RJrms.

The clause you point to in 802.3ck was for C2M where jitter tolerance and interference tolerance equivalents were combined into one test, and specifying how much Sj (and it’s frequency) is included in the test and is very important. The equivalent copper cable clause in 802.3ck (162.9.5.3) does not specify more than 802.3dj does.

Some clarification would probably help however.

From: Hadrien Louchet <000048266f3548a2-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Friday, July 11, 2025 9:36 AM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] [802.3_B400G_ELEC] Jitter profile for input test

Dear colleagues, I missed the deadline to submit a comment against Draft 2. 0, but this allows me to get your opinion on a specific aspect of the receiver input test procedure. In several places—such as clause 179. 9. 5. 3. 3 (Test channel calibration,

ZjQcmQRYFpfptBannerStart

Prioritize security for external emails:

Confirm sender and content safety before clicking links or opening attachments

Report Suspicious ‌

ZjQcmQRYFpfptBannerEnd

Dear colleagues,

I missed the deadline to submit a comment against Draft 2.0, but this allows me to get your opinion on a specific aspect of the receiver input test procedure.

In several places—such as clause 179.9.5.3.3 (Test channel calibration, CR) and annexes 176C (C2C) and 176D (C2M)—there is a recommendation to adjust the pattern generator jitter to approach practical limits (23mUI Jrms, 120muI J4u03) before injecting broadband noise. Please see the screenshot below for reference.

However, unlike the CK standard (see 120G.3.3.5.1 Host stressed input test setup), these clauses do not specify the jitter mix.

My concern is that this could lead to receivers being tested with overly simplistic jitter profiles—e.g., using only sinusoidal jitter (SJ)—which may not reflect realistic stress conditions. For example, it is possible to approach the 23 mUI Jrms target using only 50 mUI SJ.

Do you think we should clarify or tighten the guidance to ensure more representative jitter conditions?

Looking forward to your thoughts.

Best regards,
Hadrien

Best regards,

Dr. Hadrien Louchet,

Vertical Lead, Datacenter Networking
Keysight Technologies
Herrenberger Str. 130, D 71034 Boeblingen Germany
+49 7031 464 ext. 4089 T | +49 173 631 621 3 M |
email: hadrien.louchet@xxxxxxxxxxxx

Keysight Technologies Deutschland GmbH, Herrenberger Straße 130, 71034 Böblingen

Sitz der Gesellschaft: Böblingen – Amtsgericht Stuttgart HRB 747687, WEEE-Reg.-Nr. DE 26672786

Geschäftsführer: Dr. Joachim Peerlings (Vorsitzender), Thomas Götzl

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