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

Re: [802.3_ISAAC] Architectural inefficiency and PAR alignment of the 1 Gb/s proposal

All,

 

I’m looking at the reflector going back and forth going into technical details.

   

I have a couple of simple questions. 

Is 1G back channel needed all the time?   If so what is the use case?

If it is only needed once in a while what is the use case?

 

What is the market size needing 1G vs market size of not needing 1G. 

 

We already have a solution with 5GBASE-T1 or 10GBASE-T1 with EEE if you need

burst of high speed reverse traffic from time to time.  If a small fraction of the market requires 1G

backchannel, then just use the existing solution today.

 

Looking at what Ragnar pointed out, I tend to agree that the 1G modulation is not fully thought through.

Given that we want to go to SA in Nov, I recommend that we do not include the 1G. 

In my opinion, there is too much risk with the 1G proposal as it stands as I  

believe the working group is going to poke a lot of holes with this to prevent us from getting to SA. 

 

Thanks,

William

 

 

From: Ragnar Jonsson <ragnar.jonsson@xxxxxxxxx>
Sent: Monday, September 14, 2026 1:29 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: [802.3_ISAAC] Architectural inefficiency and PAR alignment of the 1 Gb/s proposal

 

Dear 802.3dm colleagues,

I have been conducting a thorough review of the proposed 1 Gb/s addition to Clause 192. I have already shared my concerns regarding whether a 1 Gb/s return path is justified for camera applications (and hence whether it aligns with the 802.3dm project scope), as well as noting that the current text is not mature enough for SA ballot without risking project delays.

In this email, I want to highlight an equally fundamental issue: the proposed framing structure is technically unoptimized, regardless of how one views the scope.

As defined in our approved Project Authorization Request (PAR), the explicit scope of IEEE P802.3dm is to specify Physical Layer standards that are:

"optimized for automotive end-node camera links for operation up to 10 Gb/s in one direction and with a lower data rate in the other direction."

When reviewing the technical details in the draft text and proposals, the framing mechanisms required to force the 1 Gb/s return path into the 9.6 µs TDD grid depart significantly from an optimized PHY architecture:

  • Excessive Byte Padding: To force transmission times into the rigid 9.6 µs TDD cycle, the datapath relies on substantial arbitrary byte padding outside the RS-FEC boundaries. Specifically, 5G+1000 requires 726 bytes (5,808 bits) of end-of-burst padding, 7.5G+1000 requires 200 bytes (1,600 bits), and the 1 Gb/s LS path requires 8 bytes (64 bits). Transmitting thousands of dummy padding bits per burst wastes channel time and transmitter power without carrying client data.
  • Severe OAM Bandwidth Squandering: In the 1 Gb/s LS path, aggregating six interleaved (L=2) RS-FEC(130,124) superframes transmits 170 bits across the 17-bit OAM positions in the five standard superframes. However, because Clause 192.3.7 strictly defines OAM exchange as a single 10-bit symbol per TDD burst, 160 out of the 170 transmitted bits (over 94%) are permanently unutilized and reserved. Carrying this dead-weight overhead solely to avoid reformatting the 100 Mb/s frame structure is remarkably inefficient.
  • Standardization of "Dark Capacity": The proposal introduces unallocated RS-FEC superframes (1 extra superframe for 1 Gb/s LS and 7.5G+1000 HS; 2 extra superframes for 5G+1000 HS), designating them as "vendor-specific" and explicitly "outside the scope of IEEE 802.3" (subclauses 192.3.2.2 and 192.3.4). Allocating standard PHY line bandwidth to proprietary, non-interoperable data simply to make the math fit the cycle timing is contrary to traditional 802.3 architectural practices.
  • Avoidable Escalation of Modulation Orders: This framing overhead inflates the symbol load, forcing the forward path to jump to higher-order modulations—from PAM2 to PAM3 for 5 Gb/s, and from PAM3 to PAM4 for 7.5 Gb/s. Sacrificing receiver SNR and link margin to transmit thousands of dummy padding bits and unused OAM positions is not an optimal engineering tradeoff for cost- and power-constrained automotive links.

While I understand the desire to reuse existing PCS building blocks, the resulting datapath layers ad-hoc shims and non-standard dark fields onto an architecture originally designed for a 100 Mb/s return path.

Given our explicit PAR mandate to develop an optimized specification, I believe the Task Force should not adopt the 1 Gb/s proposal in its current form. Standardizing a framing structure with this degree of built-in inefficiency does not serve the long-term interests of the automotive Ethernet ecosystem.

Best regards,
Ragnar

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

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