Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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 |