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
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 for Windows
From: George Zimmerman
Sent: Thursday, July 11, 2024 9:39 AM
To: 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
310-920-3860
From: Max Turner <max.turner@xxxxxxxx>
Sent: Thursday, July 11, 2024 8:01 AM
To: 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
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> 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
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