In the interference tolerance (ITOL) test it is not required to inject SJ, but “It is recommended to adjust the pattern generator jitter such that J4u03 and JRMS are as close as practical to their limits”. In practice, this requires both Gaussian and bounded jitter components. There is no recipe for how to mix these components to get close to the limits, but that is easy to do in practice if you have controlled SJ and RJ. Note that SJ distribution is different from the dual-Dirac we assume in some cases, so I would not try to prescribe a method, but in practice you likely need less than 50 mUI PtP of SJ and about 10 mUI RMS of RJ.
In the jitter tolerance ((JTOL), SJ is required with specific amplitudes. However, as currently written it is not required to inject any RJ. Using SJ only would result in less than the maximum allowed JRMS and J4u03, so it may leave a hole in the budget. it might make sense to require the same amount of RJ as used in the ITOL test.
The combination of (same RJ as in ITOL)+( SJ per the specified test cases) in JTOL will create more jitter than a transmitter is allowed. But that’s an error on the safe side.
</Adee>
From: Mike Dudek <mdudek@xxxxxxxxxxx>
Sent: Monday, July 14, 2025 11:43 PM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G_ELEC] Jitter profile for input test
Related to whether Sj is part of the test. I agree it isn’t clear (and it should be). I’ve looked back at the history and the original test was defined in clause 93.8.2.3 with references to Annex 93C. Nowhere does it say to add Sj in the interference tolerance test (although obviously it does in the Jitter Tolerance Test), but nowhere does it say not to. I can say that I for one assumed that Sj was not being added in the interference tolerance test when Annex 93C was being written.
From: Richard Mellitz <000014533bad0b9c-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 14, 2025 12:25 PM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: [EXTERNAL] Re: [802.3_B400G_ELEC] Jitter profile for input test
Does the PSD of the jitter enter into play here? It’s included in the reference receiver for the MMSE which uses Sjn(theta), Eq 178A-21. Richard Mellitz, Signal Integrity (SI) Engineer Samtec Southeast Office: 803-908-4411 www. samtec. com From:
ZjQcmQRYFpfptBannerStart
|
ZjQcmQRYFpfptBannerEnd
Does the PSD of the jitter enter into play here? It’s included in the reference receiver for the MMSE which uses Sjn(theta), Eq 178A-21.
|
From: Hadrien Louchet <000048266f3548a2-dmarc-request@xxxxxxxxxxxxxxxxx>
Sent: Monday, July 14, 2025 2:54 PM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxx.O
Subject: Re: [802.3_B400G_ELEC] Jitter profile for input test
Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. |
Hello Mike,
Thanks again for your feedback.
Regarding the new J(H)rms metric, I believe it wouldn’t differ significantly, as the reported jitter values are measured at TP0v (no channel).
You wrote:
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).
To my understanding, IEEE 802.3dj Draft 2.0 does not explicitly state that SJ should be excluded from the jitter cocktail for Itol. This is precisely the point I’d like to raise for discussion.
Looking forward to your thoughts.
Hadrien
From: Mike Dudek <mdudek@xxxxxxxxxxx>
Sent: Monday, July 14, 2025 4:57 PM
To: STDS-802-3-B400G-ELEC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_B400G_ELEC] Jitter profile for input test
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
ZjQcmQRYFpfptBannerStart
|
ZjQcmQRYFpfptBannerEnd
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
|
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
|
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
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
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
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
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
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
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
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
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