Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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> 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:
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 |