| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
George,
As all times have been defined as the maximum time, a vendor can't choose to spend more time than the maximum in any given state, even if they don't need the maximum time specified in another state.
It appears that the times in the table on page 5 of http://www.ieee802.org/3/ch/public/sep19/zimmerman_3ch_01a_0919.pdf assume the Master and Slave enter SILENT
at the exact same time. They also assume that the instant the Master transmits en_slave_tx = 1, the Slave exists the SILENT state, assuming minwait_timer_done. It seems that this will take some finite amount of time, but maybe it is small enough that it
can be ignored.
I'm just wondering if we need to have the total in each device less than 97 msec to ensure there is time to send messages back and forth and not exceed the link_fail_inhibit_timer. Maybe some of the vendors creating these parts have an idea of how much time
is needed for "handshaking".
Thanks,
Natalie
From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 4, 2019 9:12 PM To: STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx <STDS-802-3-NGAUTO@xxxxxxxxxxxxxxxxx> Subject: [802.3_NGAUTO] adhoc discussion on startup timing I was putting together the revised version of the startup timing changes (comment 169) based on what we discussed today and found a minor change is necessary.
The proposed remedy is, as discussed, to editorially have separate tables for master and slave and to define the maximum time intervals between events. However, when I came to the suggestion of constraining the total and making the time the slave spends in TRAINING (or the master spends between sending en_slave_TX = 1 to entry to COUNTDOWN) a free parameter, there may be a problem. For example, if one vendor shortens the time it spends in COUNTDOWN and TX_SWITCH (say uses 1 msec), to allow for an extra 0.5 msec in TRAINING, and another uses the maximum COUNTDOWN + TX_SWITCH time (say 1.5 msec, as Mike suggested), then the total time for training will break the budget. Similarly, if you plan on using longer time in TRAINING on slave, because you usually exit SILENT faster than 40 msec, you get in trouble if the link partner doesn't send you the en_slave_tx until 40 msec... It seems that we can't just leave the slave's time in TRAINING as a free variable and avoid an interoperability problem, so I've left it specified. I'm putting together a revised version of the presentation and submitting it to Steve for the meeting. Thank you for all the feedback. George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications george@xxxxxxxxxxxxxxxxxxxx<mailto:george@xxxxxxxxxxxxxxxxxxxx> 310-920-3860 ________________________________________________________________________ To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 To unsubscribe from the STDS-802-3-NGAUTO list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-NGAUTO&A=1 |