| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Chris, I think you touched on a key point that we need to understand. You described one perspective as “create new objectives for the same reach, with independent specs. at a lower rate and only end to end FEC.” Is it truly the case that the
new objectives would be for the same reach, or is the application more that the required reach (which in this application is really more about loss budget) falls between the reaches of two objectives? To make a more concrete example, is it that people want
to go 2 km without the inner FEC using a better Tx, or is it that they only need to go 1200 m, and the same FR transmitter that requires inner FEC to get to 2 km reach is capable of supporting 1200 m without the inner FEC?
If it’s the “better Tx” case, I agree with you that we should just specify the better Tx and not specify the inner FEC for that PHY at all. It is not good for the industry to have two non-interoperable solutions to the same problem. If it’s the “shorter reach with the same Tx” case, the ER-like approach you described is certainly one option, but I think in that context, the discussion of a new objective is a bit different – if there was agreement on what the shorter
reach needs to be, the new objective could be written for the shorter reach and perhaps with a requirement for lower latency (i.e. latency less than some value), so it wouldn’t really be replicating the 2 km objective. The task force could choose to satisfy
that hypothetical new objective by specifying the same Tx as for the 2km PHY, and not including the inner FEC. That would enable component vendors to build one part that supports both PHYs if they choose to do so, just like they could with the ER-like approach.
Note also that the ER-like approach doesn’t force vendors to build one part that supports both modes; a vendor could choose to support only the engineered-link mode and build parts without the inner FEC. One could argue those parts are not fully 802.3dj compliant,
but the customers who only need the engineered-link mode probably won’t be overly concerned about that detail.
Regards, Tom From: Chris Cole <chris@xxxxxxxxxxxxxxx>
During today's Ad Hoc call,
John D'Ambrosia's and David Law's presentation very nicely illuminated the disconnect we have in the Task Force on standardizing FEC bypass. One perspective is that we create new objectives for the same reach, with independent specs. at a lower rate and only end to end FEC. Part of the motivation is that a better TX modulator removes the need for inner FEC. If we adopt this
approach, we will have two solutions to the same problem: 1) "bad" TX with inner FEC to make up for the badness, 2) "great" TX without the need for inner FEC. Unfortunately, we have 802.3 Five Criteria to contend with. Distinct Identity clearly states there
will be one solution to one problem. If DI doesn't apply here, then we might as well discard it, and going forward only have 802.3 Four Criteria. FEC bypass should be a lower performance operating mode for the same HW. This is the basis on which I supported moving forward with it. We have to add a full set of specifications for this mode. This is why the general approach we take
for ER is good precedent. The Plug-and-play spec column is at the higher rate with inner FEC. The Engineered spec column is at the lower rate with inner FEC bypassed. An end user can then look at the spec, and for example conclude that for their shorter reach
ML clusters, the FEC bypassed mode works just fine. However, the specifications lead to one component type. The industry does not need component type proliferation driven by IEEE. That leads to market fragmentation. Alternatively, if we really believe that "good" TX technology is available, let's not bother having an inner FEC. Let's forget writing a spec for "bad' TX and write one spec. for end-to-end FEC only. Either way, we do not need new objectives. We have single 500m and 2km objectives, each with two modes (Plug-and-play and Engineered) with different levels of performance and operating parameters like rate, or just one Plug-and-play mode
without inner FEC. Chris On Mon, Aug 14, 2023 at 6:15 AM Mark Nowell (mnowell) <00000b59be7040a9-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
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 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 |