Hi Jeff,
I agree with your analysis. Sending normal AM during SLEEP and using a larger TX_SLEEP time would resolve the randomness issue.
The longer SLEEP time may lead to another problem. The RX state machine cannot proceed to the RX_QUIET state and power down until the transmitter stops transmitting (end of SLEEP); neither end can power down until SLEEP is complete. The longer the SLEEP time is, the less time will be spent in the low power state. For instance, when traffic is sparse (>>12 us between packets) then this is not a problem, but if one packet is sent every 12 us or less (less than 1% load), the link will never go into low power mode. Based on this very crude analysis, power savings would be affected at moderate load levels.
Matt Brown
AppliedMicro
mbrown@xxxxxxx
613 254 6728 office
613 852 6728 cell
Hi Matt,
I'd like to clarify what "REFRESH" is. When you view REFRESH from the Transmitter it's comprised of PCS EEE states of TX_ALERT + TX_WAKE + TX_SLEEP. While a "WAKE" cycle is just TX_ALERT + TX_WAKE.
For 10G-KR those times are:
TX_ALERT ~ 1us
TX_WAKE ~ 11us
TX_SLEEP ~ 5us
If you were to adjust the times to be the following for a 100G PHY (keeping REFRESH duration at ~17us and providing a 5us "WAKE" cycle).
TX_ALERT ~ 1us (Rapid Markers on, but overridden by PMD)
TX_WAKE ~ 4us (Rapid Markers on)
TX_SLEEP ~ 12us
The Rx would see rapid frame markers for the first ~25% of the REFRESH cycle and full scrambled data for the last 75%.
-Jeff Slavick
Avago Technologies
jeff.slavick@xxxxxxxxxxxxx On Thu, Oct 20, 2011 at 3:01 PM, Matt Brown <mbrown@xxxxxxx> wrote:
Hi Mark,
I'd like to supplement your summary of discussions on Slides 9 and 14.
For REFRESH pulses, it is not just the clock content and baseline wander
that are of concern. The REFRESH pulses are intended to give the option of
updating filter parameters at the receiver during LPI. For this to work
properly, the data must be sufficiently random. As a reference point, in
802.3ap in the startup frame we increased the training pattern (random
portion) from originally proposed 2xPRBS9 (128 octets) to 2xPRBS11 (512
octets) so that the size of the training pattern would be significantly
higher than the size of the header (36 octets) and would be sufficiently
random for robust training. Also, for 10GBASE-KR in 802.3az, the REFRESH
pulse comprises a brief ALERT signal following by a scrambled (essentially
random) LPI signal.
We discussed today that to achieve the sub-5us start-up time that rapid
AMs must be moved more closely together than 1:32, e.g., 1:8; if we do,
the systematic portion of the signal is becoming significant. We also
discussed including the rapid AMs in the REFRESH pulse; this may make the
refresh pulses less effective for the purpose they were intended for.
Cheers!
Matt Brown
AppliedMicro
mbrown@xxxxxxx
613 254 6728 office
613 852 6728 cell All,
Here are some notes from this morning's meeting EEE discussion. Thanks
to all that attended and gave feedback.
Cheers, Mark & Hugh
The discussion was focused on the presentation forwarded to the
reflector by Mark Gustlin. There was a productive and lively discussion,
certain difficulties and opportunities were raised. It was pointed out
that this proposal addressed some of the problems associated with the
PCS sublayer, there is a need for work to address the PMA/PMD sublayers
(particularly minimizing the wake time for those layers). There is also
some additional work looking at the macro-level efficiency (i.e. power
savings in practical situations with realistic traffic scenarios), which
may lead to enhancement proposals beyond the basic LPI.
Detailed notes:
Slide 4: Confusion over the multiple use of 'Wake' term in the slide.
Wake in the last bullet encompases Tw_PHY, but in the diagram it is a
box that is just a subset of Tw_PHY. Clarify the diagram labeling.
Slide 5: Add in that the .5Mb of data is per 100GE port.
Slide 7: When you bring up a link from a power downed state, you could
make the assumption that that the only changes in skew you will see are
from the skew variation portion of the skew budget, and not have to
account for the complete skew budget. This would allow you to place the
rapid AMs much closer together. This would require the receiver to
maintain skew status and the transmitter to maintain its skew (would
this limit the power savings you can achieve?). As a side note we need
to consider the impact of sending AMs very close together in terms of
'randomness' and clock content.
Slide 9: We need to consider the impact of the countdown field once we
mux together multiple PCS lanes (5 in the case of a 25G lane). What is
the impact to clock content?
Slide 10: The rapid alignment markers in this slide, with the assumption
of a spacing of 32 blocks takes up a lot of the time for the overall
wake time, can that be shortened? We will investigate the overall
budget, and look exactly when AMs transition to normal distance.
Slide 11: It was discussed that there is no need differentiate the rapid
vs. normal AMs since the state machines would have provisions in them to
ensure that the receiver is always in sync and looking for the correct
AM distance (wake time fault today does this for az).
Slide 13: In TX_ALERT PMD is sending a low frequency pattern,
independent of what the PCS is doing. This is included also as part of
the refresh.
Slide 14: Goal would be to make the state machines the same for refresh
vs. wake time as much as possible, so it likely would make sense to send
rapid AMs during the refresh as well as for wake.
Slide 16: Clause 73 also likely needs to change.
Some discussion about modular LPI vs. 'whole link' LPI. A lot of this
work would apply to both, but a lot more investigation needs to be done
on if modular LPI is needed and on how it could work.
The EEE investigation is in need of some investigation of the impact of
EEE to the PMD, Matt Brown 'volunteered' to look into it. For instance
what kind of wake time can a 100G PMDs support?
Meeting Transcript for EEE discussion
Basic Meeting Information:
Meeting Topic: EEE discussion
Host: Hugh Barrass
Meeting number: 209 626 979
Start Time: Thursday, October 20, 2011 07:55:54 AM(GMT -7:00) End Time:
Thursday, October 20, 2011 09:09:49 AM(GMT -7:00) Meeting URL:
https://cisco.webex.com/cisco
Attendee List:
Andy Moorwood, Rick rabinovich, Megha Shanbhag, Mark Gustlin, Anthony
Torza (Xilinx), Randy Perrie, Hugh Barrass, Adam Healey, Pravin Patel,
Adam Courchesne, Doug Massey, Pedro Reviriego, jgoergen, George Noh,
Velu Pillai, Matt Brown, Beth Kochuparambil, Amrik, David Chalupsky, Dan
Dove, John Ewen, David Law, ofelt, Jeff Slavick, Dave Hess, Jim Innis,
Venu B, olga mindlin, Stephen Bates, Roy Cideciyan, Wolfgang Meier,
Peter Anslow, Hecham Elkhatib, Ian Cox,
|