Glad we’re getting some mileage out of 802.3bq work.
😊
The final version of that preso was delivered in the March’14 meeting:
http://ieee802.org/3/bq/public/mar14/cibula_3bq_03a_0314.pdf
As the 802.3ck comment 18 mentions, two timers are related: link fail inhibit in the Arb machine, max wait in the PMD control machine.
To recap some of the points in Pete’s presentation:
- This presentation is from the perspective of the user, as measured performance. It is not input from PHY designers on what the value should be.
- There is an end user impact to link establishment time. Impact and target times will vary by application. Looking to an extreme example in other projects, the automotive PHYs need
an option to bring link up in ~1/4sec, because people expect their cars to work as soon as they turn the key.
- The value of these timers is not what we end user sees as the link up time. This is because if the timers are violated, the flow in the state machines is to restart autoneg and try
again. Thus it is compliant to have to go through this process multiple times before finally bringing link up.
- Even though the timers in 10G/25GBASE-T are on the order of 2 sec, many implementations take longer, whether it is due to implementation-specific tasks outside of these timers (loading
FW, running calibrations, etc.) or due to multiple passes through ANEG required to bring up a particular link.
- From a server NIC perspective, long link times are problematic in that:
- Servers do get reset, or link speeds changed periodically
- OS/driver cert tests in particular cause many resets and expect link to be up in a reasonable time.
- Long, variable link times wreak havoc in systems with multiple NICs trying to implement link aggregation.
From my observation, BASE-T products / link combinations that cannot get link with these timers rely on multiple passes through ANEG.
Also from my observation, some other product categories get around these timers simply by disabling them.
Some input from the PHY developers on what is a feasible time budget would be useful.
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, March 17, 2020 10:26 AM
To: STDS-802-3-100GEL@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_100GEL] [802.3ck] max_wait_timer comment #18 on Agenda for 18 March telephonic meeting
Ali – we considered this issue rather extensively in 802.3an, and then again, with some data in 802.3bq
I believe the equivalent timer in the multigbase-t phy set is link_fail_inhibit_timer for clause 28. If the link isn’t up by the expiration of this timer, autoneg takes over.
(note, that at the PHY Control level – in clause 55, the equivalent timer is maxwait_timer, which expires in 2000 msec +- 10msec)
Clause 28 sets the link_fail_inhibit timer duration as:
The link_fail_inhibit_timer shall expire 750 ms to 1000 ms after entering the FLP LINK GOOD
CHECK state for devices operating at 10/100/1000 Mb/s. The link_fail_inhibit_timer shall expire
2000 ms to 2250 ms after entering the FLP LINK GOOD CHECK state for devices in the
MultiGBASE-T PHY set.
Pete Cibula provided some excellent input from experience, which shows you also have to think about what happens when the initial startup fails, and more than one attempt is required.
See, for example,
http://www.ieee802.org/3/bq/public/phyproposal/cibula_01_0227_40GBT_PHY_Baseline_proposal_ad_hoc_v0p3.pdf ,
Dave Chalupsky may have other references, I don’t have time to do a more thorough search right now.
-george
Hello George,
What are the link up time allowed for 10GBAST-T and 25GBASE-T?
Thanks,
Ali Ghiasi
Ghiasi Quantum LLC
I think you’re on the right path. Somebody needs to show the analysis.
Noting that my dog isn’t in this fight, I have a lot of experience with complex PHY startups. This same discussion of what is an acceptable time to link nearly always happens.
Looking at the base text in 136.8.11.7.3, in 802.3cd I see 3 seconds was specified. In multiple PHY standards, over 3 years, 3 seconds has been a commonly accepted ‘maximum startup time’ where someone connecting a link begins to doubt that
the link is properly configured. While I can note exceptions, which took up to 30 seconds, when you have longer startup times than that, some kind of visual or other early indication that everything is proceeding OK tends to mitigate the situation (think something
more than just the spinning hourglass).
Another thing you have to consider is whether there are any other actions sequenced and pending based on the startup in question. I suggest you consider that. An electrical interface that is part of a cascade of interfaces with a long
startup may cause other parts to have ‘higher complexity’.
You also might look at whether any machine-systems (even for future use) need a specifically limited startup time (server systems typically have these interactions)
Anyhow, these are just inputs for points of discussion in the analysis to help put the choice on the right foot.
Thanks for bringing this up.
If I recall correctly, it was originally suggested to set this to 15 seconds by Jeff Slavick at the September 2018 meeting, but after discussion we changed it to TBD.
There was concern from me and others that 15 seconds is quite long, and we should not set it to that unless we had data showing that 15 seconds was required.
Looking at comment #18 I don’t see any real data on why we should set it to 15 seconds except for ‘high complexity’.
I personally would want to see some data justifying a value before choosing a value.
There is a comment (#18) on the proposed agenda for the 18 March 2020 telephonic meeting to set the max_wait_timer value. The max_wait_timer value is currently TBD in Draft 1.1. The proposed response suggests a value of 15 seconds as
the first choice or 10 seconds as the second choice.
Knowing that there are likely to be strong opinions on the topic and limited time for discussion on the call, I wanted to kick off the conversation on the reflector in order to better understand the thoughts of the participants on this
subject.
Questions and thoughts for consideration are, but not limited to:
· How big or small of a value
would make max_wait_timer unacceptable to you?
· How does the timer value impact
the ecosystem from your perspective: SERDES, systems, media, customer perception?
· What are your feedback and
experiences from lower rates (i.e. 25G/lane or 50G/lane) that can or should be applied to this rate?
Hopefully we can work towards a consensus solution in advance of the meeting.
To unsubscribe from the STDS-802-3-100GEL list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-100GEL&A=1
To unsubscribe from the STDS-802-3-100GEL list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-100GEL&A=1
To unsubscribe from the STDS-802-3-100GEL list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-100GEL&A=1
To unsubscribe from the STDS-802-3-100GEL list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-100GEL&A=1
To unsubscribe from the STDS-802-3-100GEL list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-100GEL&A=1