David,
Thanks for your feedback. Yes, I agree that a normal collision on
eMAC will result in “late” collision on the
pMAC due to the existing specification text “the
PLS_SIGNAL.indication from the RS is forwarded to both the
eMAC and the pMAC”. I realised this while preparing slide 10 and hence
just added it there with a suggested fix and forgot to list it back into Slide 6. I will add it to slide 6 as you suggested.
George,
In my slides, I did not suggest
to evoke carrier extension before an express frame transmission. Instead, I suggest having carrier extension only in the “IPG” between express packet and continuation fragment. This allows fair opportunities to
eMACs on both sides to start transmission and converge using collision.
Plus the additional benefit is that the burst due to carrier extension is limited to “1 express packet + continuation fragment”.
Lokesh
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: 08 February 2022 22:57
To: STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_SPEP2P] [802.3de] Half-duplex issues in MACMerge
David –
Reading the below, it seems to me that a collision that occurs near the start of an express packet would be interpreted as a late collision by the pMAC (as you say, more than 512 bits have
passed), but is not necessarily a late collision for the eMAC, since it would be within the first 512 bit times of the eMAC. Further, I think that for 10BASE-T1S networks (which have no repeaters and short propagation delay) the modification to clause 99
to extend carrier for half duplex systems eliminates this collision possibility.
Or am I missing something?
-george
From:
stds-802-3-spep2p@xxxxxxxxxxxxxxxxx <stds-802-3-spep2p@xxxxxxxxxxxxxxxxx>
On Behalf Of Law, David
Sent: Tuesday, February 8, 2022 9:18 AM
To: IEEE P802.3de Task Force <stds-802-3-spep2p@xxxxxxxx>
Subject: RE: [802.3de] Half-duplex issues in MACMerge
Hi Lokesh,
Thank you very much for this excellent contribution.
I'd like to start with a minor comment on slide 6 'Collision Scenarios in MACMERGE 1' and slide 10 'Summary of Collision Issues'. Since, based on subclause 99.4.5 and 99.4.6 of the current
IEEE P802.3de draft, the PLS_SIGNAL.indication from the RS is forwarded to both the eMAC and the pMAC, I believe that a late collision can occur either when the pMAC is transmitting a continuation fragment, or when the eMAC is transmitting an express packet
that has pre-empted a pMAC packet.
I believe that any collision that occurs after the transmission of more than 512 bits by a MAC is classified as a late collision. See WatchForCollision procedure in subclause 4.2.8 where
lateCollisionError is set true if (currentTransmitBit > (slotTime - headerSize). The headerSize is subtracted from slotTime as currentTransmitBit only starts counting after the header is sent, see BitTransmitter process 4.2.8.
I also believe that Figure 99-5 'Transmit Processing state diagram' will always ensure that the pMAC has transmitted a minimum of 512 bits before it can be pre-empted by the eMAC. The
transition from the PREEMPTABLE_TX state to the TX_MCRC state is conditioned on preempt being true. The varible preempt is defined as true when pAllow * (eTx + hold) * preemptableFragSize * MIN_REMAIN, and preemptableFragSize is defined as true when fragSize
>= (minFrag x (1 + addFragSize) – 4) where fragSize is a count of the number of octets of mData transmitted in the current preemptable mPacket, and where minFrag is 64 bytes.
As a result, should a pre-emptiable packet be preempted by an express packet, since the express packet will not be sent until after a minimum of 64-byte fragment of the pre-emptiable
packet has been sent, a collision that occurs at any point within the express packet that will be forwarded to both the eMAC and pMAC will be considered a late collision by the pMAC. I've captured an example of this in the trace below from my Verilog model
of the system you illustrate on slide 3 of your contribution.
The fix is already listed on slide 6 of your contribution, the PLS_SIGNAL.indication from the RS should only be forwarded to the transmitting MAC. So, as I said, a minor point, but for
completeness I suggest that slide 6 and slide 10 list that a late collision can occur when the eMAC is transmitting an express packet that has pre-empted a pMAC packet, based on the current draft forwarding collision events to both MACs.
Best regards,
David
-----
-----
From: Lokesh Kabra
00001479dd556d60-dmarc-request@xxxxxxxxxxxxxxxxx
Sent: 02 February 2022 12:31
To:
STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: [802.3_SPEP2P] FW: [802.3de] Half-duplex issues in MACMerge
Hello all,
As discussed in the meeting yesterday, we had offline discussions on the half-duplex issues and possible fixes to support it in MACMERGE.
The details of the problem scenarios/issues and possible solutions for the identified problem is captured in attached presentation.
I would like the larger group to review this and join the discussion in case we have missed out any more hidden issues or suggest better solutions for fixing the issues.
Once we have some consensus on the solution, exact changes to the next draft can be submitted in review of D2.1.
Thanks,
Lokesh
From: George Zimmerman <mailto:george@xxxxxxxxxxxxxxxxxxxx>
Sent: 01 February 2022 21:44
To:
mailto:STDS-802-3-SPEP2P@xxxxxxxxxxxxxxxxx
Subject: [802.3_SPEP2P] [802.3de] website update
The 802.3de website has been updated with our two presentations for today.
As of this moment, I don’t have a volunteer to be recording secretary. If you would like to volunteer, please let me know. However, in the lack of a volunteer, I will ask the group’s
consent and am willing to also serve as recording secretary.
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications
mailto:george@xxxxxxxxxxxxxxxxxxxx
310-920-3860
________________________________________
To unsubscribe from the STDS-802-3-SPEP2P list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1
________________________________________
To unsubscribe from the STDS-802-3-SPEP2P list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1
________________________________________
To unsubscribe from the STDS-802-3-SPEP2P list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1
To unsubscribe from the STDS-802-3-SPEP2P list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1
To unsubscribe from the STDS-802-3-SPEP2P list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1
To unsubscribe from the STDS-802-3-SPEP2P list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1