| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Hi Pete,  100ms provides an upper-bound which needs to be met by default so it is not necessary to specify it again. Iâ??d like the second one better because it is optional and left to the implementer and the application owner what run-time configuration will be as there will be many different operational modes possible. Therefore, weâ??d leave it to the application define and drive that.  Kind regards, Mehmet  From: Peter Jones (petejone) [mailto:petejone@xxxxxxxxx]  Folks,  Iâ??m not disputing the need for fast startup.  Iâ??m trying to figure out the real difference (from what we would put in our standard) between the following two. Â
And â?¢Â      Support optional operation with run-time configuration, that specifies a maximum allowable time from power_on **=FALSE to a state capable of transmitting and receiving valid data.  The difference seems to be in the time required to process the â??run-time configurationâ??, and this seems to be out of scope for a PHY project.  Am I reading this wrong? What do you see as being included in the case with run-time configuration thatâ??s not included in the â??predetermined configurationâ?? case.  Regards Peter  _______________________________________________ Peter Jones            Cisco Systems Principal Engineer     560 McCarthy Blvd. Campus Switching S/W   Milpitas, CA, 95035 USA Wrk: +1 408 525 6952   Mob: +1 408 315 8024 Email:                 petejone at cisco.com Twitter:               @petergjones LinkedIn:              /in/petergjones _______________________________________________  From: Bob Voss [mailto:Bob.Voss@xxxxxxxxxxx]  Dear all,  Fast start up is needed in Industrial Automation as well. These links will need to recover quickly as do other Ethernet links in Industrial networks.  Regards, Bob From: Kirsten Matheus <Kirsten.Matheus@xxxxxx>  Dear all,  fast start up is an extremely important requirement in automotive. We had it in 1000BASE-T1 and I would like to keep it. If it is not needed for 1000m, we should say so in the text. There are other things we do not need for 15m and we should find a way to say that too.  Kind regards, Kirsten    Von: Peter Jones (petejone) [mailto:petejone@xxxxxxxxx]  Hi Folks,  This is one that I have trouble with.  I think what is troubling is that with â??run-timeâ?? configuration in place, there is some level of system/SW function required between power-on and fully operational. Without bounding that, I donâ??t see how we can specify a maximum time. The maximum time has to be â??system_time + phy_timeâ??.  I think the â??phy_timeâ?? term in this case is the same as George listed in proposed objective 13 (below), e.g. 100ms. 13. Support fast-startup operation using predetermined configurations which enables the time from power_on**=FALSE to a state capable of transmitting and receiving valid data to be less than 100ms.  I donâ??t think that we can usefully specify limitations on the system_time, so I donâ??t see that this additional proposed objective adds value.  Regards Peter   _______________________________________________ Peter Jones            Cisco Systems Principal Engineer     560 McCarthy Blvd. Campus Switching S/W   Milpitas, CA, 95035 USA Wrk: +1 408 525 6952   Mob: +1 408 315 8024 Email:                 petejone at cisco.com Twitter:               @petergjones LinkedIn:              /in/petergjones _______________________________________________  From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]  In addition to objective #13 (<100msec startup on predetermined configurations) we have had the following objective proposed:  â?¢Â      Support optional operation with run-time configuration, that specifies a maximum allowable time from power_on **=FALSE to a state capable of transmitting and receiving valid data.  The issue is that this seems to need some clarity as to how it differs from objective #13, fast startup in predetermined configurations. Can someone either provide the clarity, and, preferably, reword so that it is clearly different from objective 13?    George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860  |