| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Kirsten – We are a study group, and can explore the suitability, but I think a lot of work would need to be done, and it would take a lot of time and review. This isn’t about seeing one presentation, it’s about iterating,
reviewing, thinking, and cross-checking. My experience in 802.3cg and 802.3de with half-duplex has taught me just how nuanced and uncommon knowledge of the details of the half-duplex mac is, and I would not want to go there quickly. There are a bunch of reasons for saying ‘full duplex’ only – but the ultra short answer is that 802.3 half-duplex MAC operation is not defined at greater than 1 Gb/s. Table 4-2 doesn’t have the parameters
needed for the half-duplex MAC to run at more than 1 Gb/s. We need to craft distinct identity, and being half-duplex would resolve that – however, it comes with a lot of complications. I’ve lived them recently and don’t recommend that route. We should probably say full-duplex only
at the MAC/PLS service interface to make it clear we are talking about the MAC – the phy duplexing mechanism on the medium. Because we’d need to touch clause 4, unless we want a MAC project, and IMHO a long, complicated one at that, there needs to be a big advantage to using the half-duplex MAC. The advantage we’re looking for
is PHY based. If there is a substantial technical advantage that can’t be gotten another way, presentations need to support it. If the physical layer interfaces to the full-duplex 802.3 MAC we get the benefit without half-duplex.
While supporting the half-duplex MAC resolves the political problem of making distinct identity easy, it creates its own pain, and first among these is that touching the MAC appears to break the CSD of ‘compatibility’.
It also creates the possibility and discussion of a new 802 “dot” group. You mention that there are gigabit PHYs that support half-duplex MACs. Yes, that is where the pain was seen. At 1 Gb/s, 802.3 had to touch the MAC to continue to support half-duplex, and, as a result, agreed
to abandon half-duplex above 1 Gb/s. We’d be breaking additional new ground at greater than 1 Gb/s and probably have to make the scope include the MAC, which comes with more complexity and fewer good reviewers (I suspect even fewer than the RS). Further,
even if we did it, beyond 100 Mb/s, half-duplex really hasn’t been used, so even the mods to make gigabit work don’t have much track record. Modern Ethernet is, with the exception of PLCA, designed to be full-duplex
at the MAC/PLS service interface. And part of the reason PLCA works is because it is at a low rate on a short medium. This avoids the root cause of the complexity - the relation of collision delay to the bit time (and the time duration of
a minimum size frame). Minimum frame size which is 72 octets or 576 bits. The rough delay of our transmission medium is 4.8 to 6 ns/m. Let’s say 5.5 as a round number (which agrees with many cabling specs) – that means a 10m cable has a round trip delay
of 110nsec. 1 Gb/s at 100m was 1100 bit times, hence the problem (addressed by extending carrier on minimum size frames at the cost of efficiency). 10 Gb/s at 10 m would be the same. So it might get around this up to 5 Gb/s, or with kludges like 1 Gb/s,
but as far as I know, 1Gb/s half-duplex IS NOT USED, and hence is untested in the world… Not that we couldn’t craft something, but it would be new and require a lot of reviewing. PLCA was hard to get right. We can’t just use PLCA because PLCA relies on a medium that has a short delay relative
to the bit time, just like half-duplex itself. (and, IMHO, the only reason we got PLCA through as not being a MAC change is because it is compatible with CSMA/CD operation with non-PLCA nodes on the mixing segment). Note also that PLCA stuck with the RS,
and played well with the existing parameters of the half-duplex MAC. Something we can’t do, because the speed changes. And don’t forget that most of the modern TSN work was done for full-duplex (with, adaptations for PLCA, but we’d need more… I could give a bunch more reasons (which I sent personally), but there be dragons here – we need a pretty strong reason to go the direction of supporting other than full duplex only at the MAC/PLS service
interface. -george From: Kirsten Matheus <Kirsten.Matheus@xxxxxx>
Dear all,
On page 13 of the slide shown during the ISAAC meeting on Wednesday August 16, suggestions for general objectives are listed (see https://www.ieee802.org/3/ISAAC/public/081623/PAR_CSD_OBJ_081623_01.pdf).
I concur with the first five objectives listed under “general and automotive objectives”, but I would like to discuss and understand better the rationale behind the suggestion to limit the technical solutions to “support full duplex operation only”.
Following thoughts occur:
In consequence, I propose to explore the suitability of a half-duplex PHY at this point in time and to not have the constraint of supporting full duplex MAC.
I am happy to propose to immediately adopt the first five objectives in the list and to remove “support full duplex operation only” (similar to what was done for the original objectives for 10BASE-T1S, see https://www.ieee802.org/3/10SPE/objectives_10SPE_111016.pdf). Kind regards, Kirsten 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 |