Re: [802.3_NGAUTO] possible eee state machine issues with temporary lpi exit

[George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>]

Jim – I’ve been talking with some of the guys and what we have here is kind of tied up with the definition of the LPI client (as well as the pervasive management interface) – frankly, I think that’s out of the scope of the 802.3ch project, and we left it vendor-defined for a reason.  Because the management interface is pervasive, we can use that for the system-level knowledge, and consider the communications done.  I’d like to see the definition transparent to the XGMII, and well-defined there, but at this time don’t want to open a can of worms in the project.

 

We can go with just adding the minimal recirculating arc to fix the known problem, and let the wake-up go through the normal alert path as you suggest.

It would probably be a good idea to put a presentation to the group at the next ad hoc to show the change.  I’d be happy to work with you on it.

 

-george

 

From: Jim Graba <james.graba@xxxxxxxxxxxx>
Sent: Thursday, December 19, 2019 7:13 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGAUTO] possible eee state machine issues with temporary lpi exit

 

The temporary exit from LPI is intended to be temporary. A temporary Alert based LPI exit shouldn't last long and won't impact the the MAC side layers' power. 

There is a cost to supporting another LPI exit mode. I don't agree that this cost is worth the benefit.

 

Jim

 

On Wed, Dec 18, 2019 at 5:23 PM George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:

I disagree on the alert. in this case, the receiving PMA knows it requested the return to normal idle, and doesn’t need the alert.  the far end doesn’t have the option of not complying.

 

As far as the upper layers – we agree – we DON’T specify what they do, but we do specify what is signaled.

Internally to the phy, the sublayers we do specify -  as far as the decoder, the PCS and the XGMII, a regular transition requires that we send those signals. 

Beyond the XGMII, what we’re doing locks us into whatever action the rest of the system takes in a return to normal data, since we don’t provide any signaling.  There is no specified interface to provide MAC on the other side of the XGMII the fact that the PHY requested this temporary transition -  it has to treat the alert as a return to normal data mode.  the LPI client doesn’t get any information that this isn’t a real return to data.  how will it make any other decision if we don’t specify way for it to know the difference?  better to hide the whole thing.

From: Jim Graba <james.graba@xxxxxxxxxxxx>
Sent: Wednesday, December 18, 2019 4:12 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGAUTO] possible eee state machine issues with temporary lpi exit

 

The transmitter needs to send an ALERT on the MDI to signal the receiving PMA to wake up. Otherwise the receiving PMA will be expecting Quiet/Refresh and will drop the MDI link if it receives anything else.

 

I claim it's simplest for the transmitting PHY to perform a Wake sequence including sending Alert. After that the transmitting PHY should send Idles until:

a) The requesting PHY indicates it's OK to enter LPI via OAM or

b) The transmitting PHY's MAC sends data.

 

I believe we need not specify or dictate the requesting PHY's upper layers' response to this temporary LPI departure. Each vendor can develop their own.

 

Jim 

 

On Wed, Dec 18, 2019 at 4:30 PM George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:

Jim – thanks for the confirmation that there is an issue.

I don’t see why we would want to wake the whole thing up though – it’s more than just the receiver, and the stated purpose of this ‘temporary exit’ is to restore PMA timing and coefficients due to low SNR.

Remember that it isn’t just the receiver that wakes up if we send an ALERT.  we then send LPI to the MAC over the XGMII, which is indistinguishable from a real event where traffic is coming.  If the microcontroller and other processing circuitry are managing power per EEE, this is wasteful.

You don’t actually need an ALERT in this case, and you don’t even need to align it – you should just be able to start transmitting normal idles.  Further, you don’t even have to decode them with the RS-FEC.

 

In the case of the temporary wake-up, you have the advantage that the local receiver knows that the transition out of quiet-refresh is coming, because it requested it due to low SNR.  There should be no reason to go any further than the PMA, and then you can go right back into power-saving mode…

 

-george

From: Jim Graba <james.graba@xxxxxxxxxxxx>
Sent: Wednesday, December 18, 2019 3:19 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_NGAUTO] possible eee state machine issues with temporary lpi exit

 

Hi George,

 

Our intent was if LP0 indicated low SNR in the OAM LP1 would send an Alert. And then LP0's receiver would fully wake up.

 

I agree with your assessment of the state machine's consistency. This is a good catch. I'll work on a solution and we can hash it out in this space.

 

Jim

 

On Wed, Dec 18, 2019 at 1:01 PM George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx> wrote:

EEE-wise folk:

I’m looking at the state diagrams for the PCS in the document, and it looks like there may be one or more issues in the temporary EEE exit due to low SNR.

 

You’ll note that when this happens, we do not get a ‘wake’ code from the MII, but rather are receiving an lp_low_snr from the PMA from the link partner.

 

The first issue is in Figure 149-17.

It appears that TX_WN may need a recirculating function if it is supposed to wait until tx_lpi_active is false before exiting, and continuously re-evaluate the condition tx_alert_start_next.  State diagrams only evaluate the condition on entry to a state.  Otherwise, if tx_alert_start_next were false on entry, TX_WN would enter, set tx_coded to IBLOCK_T and exit with tx_lpi_req possibly still in the true state (for example, if LPI is being exited due to a low SNR message).  According to Figure 149-20, tx_lpi_active is set FALSE in TX_NORMAL and TRUE in SEND_SLEEP, which can only be exited by tx_lpi_req going to false.

 

tx_lpi_req is described as “A Boolean variable that is set true when the LPI client indicates that it is requesting operation in the LPI transmit mode via the XGMII. It is set false otherwise.”  Clearly, this is not the case with the temporary exit.

 

The second issue is with the same figure – it isn’t clear that we re-enter quiet-refresh signaling cleanly.  Assuming that tx_lpi_req gets set to false to fix the above, and Figure 149-20 gets back to the TX_NORMAL state, you can’t get back to the SEND_SLEEP state and hence into SEND_QR unless tx_lpi_req

 

The second possible issue is one of intent.  – is it our intent to fully wake up the far-end with a low-snr exit?  the way it is now (assuming the above gets changed), an exit from quiet-refresh signaling via an ALERT from the far end transmitter would result in the receiver getting an alert and processing it just like a real wake-up. 

 

All of these come down to intent, and there are multiple ways to fix it (I’m thinking the simplest is to have the temporary wake up happen without an ALERT, and hence no change in the receiver PCS state.  that way the receive PCS stays asleep and presents LII to its XGMII.  However, to do that, you need to change Figure 149-17 so that you don’t exit TX_WN on a low SNR condition, but do something that recirculates back to TX_L when the low SNR condition is gone.  You also need to add a state for Figure 149-20 which exits SEND_QR on low SNR and reenters it when the condition is gone. 

 

 

Before I put in the work to propose a solution, since it all just twists my brain into a pretzel, I thought I’d check and see if I was missing something simple.

 

 

George Zimmerman, Ph.D.

President & Principal

CME Consulting, Inc.

Experts in Advanced PHYsical Communications

george@xxxxxxxxxxxxxxxxxxxx

310-920-3860

 

---

To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1

---

To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1

---

To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1