Mark –
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.
-george
Kent,
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.
Thanks, Mark
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