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

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