I lied. my call ended and I did have time.
Here is the updated, follow-up from Pete’s presentation
http://www.ieee802.org/3/bq/public/mar14/cibula_3bq_03a_0314.pdf
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