Re: [802.3_ISAAC] Presentation for the July Plenary
Hi All,
I would like to add my thanks for the discussion and considerable thought on this topic.
If one accepts the premise that the xMII must be full-duplex rate-symmetric running at the maximum speed available on the line, then the conclusion that a full duplex PHY requires less buffering and simplifies the MAC transmission scheduling follows. However, it doesn't follow that a full duplex PHY is advantageous for meeting the 802.3dm objectives or that a TDD PHY isn't the best way to address the 802.3dm objectives.
If we discard the premise of full-duplex rate-symmetric xMII and allow the desired upstream MAC/xMII/link rate to better match each other, then the TDD PHY and MAC transmission scheduling can likely be simplified and further optimized.
So I look forward to some conclusion on whether it's possible to move forward with a non-symmetric full-duplex xMII, or if there are good reasons to work under the rate-symmetric xMII constraint.
Best Regards,
Scott
-----Original Message-----
From: Kamal Dalmia <kamal@xxxxxxxxxxxxxx>
Sent: Friday, July 12, 2024 11:05 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_ISAAC] Presentation for the July Plenary
EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
Hi Ahmad,
Thanks for a good explanation of how an 802.3 system would work with a TDD PHY. I fully agree with the following –
“On the TX side, the FIFO is written continuously. TDD cycles are periodic. During silent periods the FIFO is filled up. During active periods data is read from FIFO at a higher speed. Therefore the FIFO does not overflow. Data continue to be written at 100Mbps even during active periods, no interrupt is required.
On the RX side, FIFO is written to, at high speed during active periods and read at slower rate of 100Mbps continuously. Before the FIFO is emptied completely, a new batch of data is written in the next TDD cycle into the FIFO.”
I would add further that the above scheme makes TDD PHY indistinguishable from other PHY types to the upper layers. MAC and higher layers would neither have any knowledge of the underlying PHY mechanism nor need to have the knowledge.
George said the same thing below in different words – “the PHY isn’t supposed to know about frames”. I fully agree with this as well.
It should also be noted that all PHYs that involve forward error correction have some level of buffering to store bits and then calculate and append error correction bits. The FIFO above is in the range of typical PHY (FEC driven) buffers as opposed to upper layer Frame based buffering which is driven by congestion etc.
Regards,
Kamal
From: Ahmad Chini <chiniahmad.ieee@xxxxxxxxx>
Date: Friday, July 12, 2024 at 10:09 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx <STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] Presentation for the July Plenary
CAUTION: This email is from an external origin!
Hi George
The 125 Bytes FIFO that I mentioned for an example TDD cycle, supports continuous stream of data, short, long or jumbo packet. Here is a brief explanation how it works.
On the TX side, the FIFO is written continuously. TDD cycles are periodic. During silent periods the FIFO is filled up. During active periods data is read from FIFO at a higher speed. Therefore the FIFO does not overflow. Data continue to be written at 100Mbps even during active periods, no interrupt is required.
On the RX side, FIFO is written to, at high speed during active periods and read at slower rate of 100Mbps continuously. Before the FIFO is emptied completely, a new batch of data is written in the next TDD cycle into the FIFO.
In a way you can think of TDD+FIFO doing the segmentation and reassembly automatically.
Alternatively if 802.3dm decides to use high speed interface, task force may discuss what FIFOs are needed for FDD/TDD/EEE. Added complexity in practice when such a PHY is integrated in a switch, serializer or deserializer may also be discussed and quantified.
I suppose there will be multiple presentations on the topic of MAC/PHY interface and implications including added FIFO requirements for all possible asymmetric links.
Regards
Ahmad
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
From: George Zimmerman<mailto:george@xxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, July 11, 2024 12:02 PM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] Presentation for the July Plenary
Ahmad –
Definitely issues to be discussed, but I believe the relation of buffering on TDD to MII is a false one. The structure of the MII only determines where the extra buffer might be. On the RS side of the MII or on the PCS side of the MII….
Your pointing to fifos and rate-adapting buffers below suggests you see the same thing… I would point out, however, that 125 bytes is probably not sufficient if maximum length ethernet frames are supported and are intended to be held back by carrier sense… This might be solved by fragmentation and reassembly somewhere (similar to what Max suggests with preemption, I believe).
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications george@xxxxxxxxxxxxxxxxxxxx<mailto:george@xxxxxxxxxxxxxxxxxxxx>
310-920-3860
From: Ahmad Chini <chiniahmad.ieee@xxxxxxxxx>
Sent: Thursday, July 11, 2024 11:35 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>; STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_ISAAC] Presentation for the July Plenary
George
I agree that this subject needs to be discussed. But before that the MII interface needs to be decided.
For example of EEE ,there are signaling defined in the reconciliation sublayer that allows deferring traffic until PHY is woken up, e.g. 16us for 1000BASE-T (not T1). The interface defined for MII is a logical interface. Since the traffic control signaling (carrier indication) does not pass to MII interface, practically buffers are installed below MII interface to receive data as it arrives and generate LPI signaling below MII Interface.
So, one way to address this issue is to use carrier indication to defer traffic until PHY is ready. Details of that approach is TBD.
Another possible way is to define the MII interface for example 2.5G/5G/10G in one direction and 100M in another direction. There is a simple way in this case to convert a TDD signaling into continuous bit stream with no hold at MII. For example if 100M direction is 10us off, use 10us x (100Mbps)=125Byte FIFOs in both TX/RX.
There is however a problem in general regardless of TDD/FDD, if 802.3dm task force defines a 100M MII interface. For zonal applications, there is a significant added latency going through an Ethernet switch at 100M interface as compared to 2.5/5/10G interface (multiple presentations are available in the past 802.3)
My preferred solution is to keep the logical MII interface a high speed in both direction so that latency in Ethernet Switch is minimized. If 802.3 decides on such an approach, then we will need to use rate adapting FIFOs in FDD, TDD or EEE on both sides of the link. For integrated solutions, there may not be a need to separate PHY rate adapting FIFOs from application and MAC buffers.
Thanks
Ahmad
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
From: George Zimmerman<mailto:george@xxxxxxxxxxxxxxxxxxxx>
Sent: Thursday, July 11, 2024 9:39 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] Presentation for the July Plenary
Max – thanks for this update – your slides 9 through 11 point at the issues here that I am trying to wrap my head around – the relationship between the gate-open time and the ethernet frame size. It seems that you have to have an extra frame buffer either above the xMII or within the PHY to accommodate mismatch of an offered Ethernet frame to the PHY timing unless the frames are somehow synchronized to the gate time – and synchronizing to the gate time within the PHY would break layering… (I was thinking about this in regards to Kirsten & Kamal’s presentation on latency – dealing with that mismatch is an inherent additional buffer in a TDD system, I haven’t seen a way around it. You may argue it isn’t large, but I’m not seeing a way around the synchronization and the buffer needs to be accounted…)
As you say, the PHY doesn’t usually know about frames – I would say, the PHY isn’t supposed to know about frames.
Using something like preemption (e.g., clause 99 - which is defined when you have 2 MAC queues competing for the medium…) is an interesting notion for fragmenting a frame, but I would see this as just allowing a smaller maximum frame size. Is there something else here you are trying to communicate?
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications george@xxxxxxxxxxxxxxxxxxxx<mailto:george@xxxxxxxxxxxxxxxxxxxx>
310-920-3860
From: Max Turner <max.turner@xxxxxxxx<mailto:max.turner@xxxxxxxx>>
Sent: Thursday, July 11, 2024 8:01 AM
To: STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-ISAAC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_ISAAC] Presentation for the July Plenary
Dear all!
Thanks to everybody who took the time to look over my initial presentation draft and gave feedback. I took your input and questions to hopefully improve the presentation in terms of clarity and ease of understanding.
Here is an update to be presented next week.
Best
Max
--
Max Turner, Dipl.Phys.
Automotive Network Architect
Ethernovia BV
Utrechtseweg 75
3702AA Zeist
The Netherlands
https://www.ethernovia.com/
c-de: +49 177 863 7804
c-nl: +31 685 386 449
On Tue, Jul 2, 2024 at 9:31 AM Max Turner <max.turner@xxxxxxxx<mailto:max.turner@xxxxxxxx>> wrote:
Dear all!
Please find attached my slides for the .3dm session during the July Plenary.
Feedback and questions up front are very welcome!
Best
Max
--
Max Turner, Dipl.Phys.
Automotive Network Architect
Ethernovia BV
Utrechtseweg 75
3702AA Zeist
The Netherlands
https://www.ethernovia.com/
c-de: +49 177 863 7804
c-nl: +31 685 386 449
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
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
________________________________
This email has been scanned for spam and viruses by Proofpoint Essentials. Click here<https://us2.proofpointessentials.com/app/report_spam.php?mod_id=11&mod_option=logitem&report=1&type=easyspam&k=k1&payload=53616c7465645f5f43881a75e1e764e6aa7acf3e6ce70c9ca5f043c6e041630e1ba895ffd734ba49f7347a0739b085ce57b156b85fc55c2b94ed6c08b42867e64ee52010f8f916e4daa1a49dfad63a02a9b00d6ed9fbe363dab5bf7bfa445a7bf9a574b06a368c0947665a49c2152ac670227a08f9442f786dc018fa33479c5ff7775ad34af99caf093c306f7e3b9a78ede5634a13025c3a91df3b264b9d89a0> to report this email as spam.
________________________________
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
________________________________________________________________________
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