I appreciate you raising your concerns to the group and am hoping that you will be part of the efforts to bring in
data and/or analysis in support of, or against, some of these many tests we have adopted. I just sent an email to the Task Force reflector highlighting my overall concerns on the broader topics here that we need to reconcile the full suite of
tests we have currently adopted.
I do however take issue with some of your points below regarding how the Task Force works and how we will continue to work.
At each increase in speed, we continue to see the intermingling of issues between all aspects of our work in the 3 categories of our work electrical/logic/optical as we work to resolve the technology and implementation issues. The margins we are dealing with
become ever tighter meaning that this trend is not going away.
In a Task Force, we would ideally all meet together for every technical discussion as the expertise needed to resolve each topic often spans across domains. We write stronger specifications as a result. With P802.3dj we have a situation where the current
volume of work dwarves our ability to do it all together and we necessarily have been splitting into tracks so we can to allow parallel work. As we triage the comments that come in, the leadership team and the editorial team do considerable work to pull together
a plan to optimize how we a) get the work done and b) aim for the highest quality of work in the limited time.
This results with meeting plans, that you are familiar with, where we pull together the topics and meeting room availability to try and have a successful meeting. We know that a blend of common time for topics and specific track time is the most successful
outcome with our current workloads and we have no plan to change that. We have numerous participants who put in considerable time submitting comments and in respect for that work we aim to ensure we can manage schedules in support of everyone if we can.
Thank you for your input regarding that one topic of concern you have. We will take it into consideration. But per the email I just sent to the Task Force, I’m elevating this broader issue of SMF test methodologies as one of our big-ticket items that needs
to be resolved in November so that it doesn’t start risking overall project schedule. We know we have broad expertise across the Task Force which will help us resolve the issues and we will be planning accordingly to give us the highest probabilities of getting
the work done and getting the most robust outcomes.
The leadership team and editorial team will once again triage the comments and the work ahead for the November meeting and map that into meeting times and track times. This is not a trivial effort and if you want to join all of the 2+ weeks of multiple times
a day, daily planning meetings that occur here to achieve this let us know.
From: Chris Cole <chris.cole@xxxxxxxxxxxx>
Date: Tuesday, October 7, 2025 at 6:07 PM
To: STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx <STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_B400G_OPTX] Transmitter testing
Dear 802.3dj Optics Track Participants,
During the September interim, in multiple conversations, the question came up why Comment #399 was resolved in a joint electrical optical track meeting. After all this is a purely optical spec, which has no effect on any electrical link because the receiver
is fully retimed.
Today, during an informal off-line SMF consensus building discussion today, we learned the reason why. It was pointed out that transmitter jitter has an effect on DSP design, and DSP is electrical.
While this is absolutely true, it is not how we should determine which track specs belong in. This should be determined by what link they effect. Specs that effect only electrical or optical links should be resolved in separate electrical or optical tracks,
respectively. Specs that effect both should be resolved jointly.
Further, almost every spec in the Transmitter Characteristics table has electrical circuits associated with it, like Drivers, or effects electrical circuits in the receiver, like TIA. The only two specs that I found that could be argued not to effect electrical
circuits are Optical return loss tolerance and Transmitter reflectance. If we were to consistently apply the rule that if a spec has effect on an electrical circuit, even if only used for optical functions, then there is no need for an optical track, or optical
comment resolution. Everything should be considered in a joint electrical/optical track. Viewing this as unreasonable is not naive, as was characterized today, but rather common sense.
Hopefully during the November Plenary optical jitter will be correctly assigned to the optical track for resolution, since its only effect is on the optical link. If not, then hopefully a better and more consistent rationale will be given than the above.
Thank you
Chris
From: Chris Cole <chris.cole@xxxxxxxxxxxx>
Sent: Monday, September 22, 2025 1:28 PM
To: STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx <STDS-802-3-B400G-OPTX@xxxxxxxxxxxxxxxxx>
Subject: [802.3_B400G_OPTX] Transmitter testing
Dear 802.3dj Optics Track Participants,
During last week's Interim meeting, Comment #399 against D2.1 was resolved by adding a jitter test to Transmitter compliance. This was unfortunate for a number of reasons, which a group of optics experts captured in a post deadline presentation.
The technical discussion around the presentation was cut short, so we have requested from the Optics Track Chair that we find time to continue the discussion.
There are many reasons why adding a jitter test in the manner in which it happened is problematic, and two stand out.
This issue has been discussed in multiple Optical Track calls over the past year and it has had no support from the optical community, as exemplified by lack of optics supporters on the comment. During comment #399 resolution, multiple optics experts spoke
against adding this test, and no optics experts spoke in favor.
802.3 is part of a greater ecosystem. We need to have mutual respect for each other's expertise and 802.3 forcing a test on a segment of the industry that does not want it, only undermines 802.3 credibility. Regardless of whether this test is part of the standard,
those that build and deploy optics are not going to use it. As it is, optics testing is expensive, and increasing the cost without a clear benefit is not going to happen.
Jitter problems are captured by the recently added functional test. In fact, comment #399 proposal showed this by using a BER test to illustrate jitter issues. If BER test is the ultimate arbiter of jitter problems, why bother with an additional indirect test?
During the brief discussion of the above presentation, concerns were raised about the ability of a functional test to catch jitter issues, for example the functional receiver having a pathological jitter tracking bandwidth. We need a forum to talk through
these concerns. Although in this case the answer is the same as a doctor gives a patient with headaches who bangs his head against the wall: don't do it.
Towards the Nov. the Plenary meeting, we will be working on a presentation to remove jitter testing from transmitter compliance and asking for broad optics industry support.
Thank you
Chris
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
To unsubscribe from the STDS-802-3-B400G list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-B400G&A=1