|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Thank you for following up and thinking about this, and thank you for the excellent presentation. We all learn from each other, and your contribution helped.
Regarding 802.3as time – isn’t it directly linked to the bit time clock? If so, so is the beacon.
However, it was my understanding that the timing information was inserted by the TSSI (defined in 802.3-2015 Clause 90), which David showed would work for normal CSMA/CD.
We might benefit from a look at the compatibility of the TSSI with the proposal adopted, and any adjustments that might be needed.
Again, thank you,
George A. Zimmerman, Ph.D.
Chair, IEEE P802.3cg 10Mbps Single Pair Ethernet Task Force
President & Principal Consultant
CME Consulting, Inc.
Experts in PHYsical Layer Communications
What a great meeting we had last week. I learned a lot.
Over the last couple of days I’ve been thinking about running TSN shapers on top of the new PLCA proposal (by the way, what are we going to call it? I need an acronym). Many of the TSN shapers, policers, and other capabilities are synchronized to the 802.1AS clock; this is how they provide the “guarantees” they can across multiple media types.
On Thursday we learned about the Beacon concept in the new PLCA proposal. My concern is that if that Beacon is completely unrelated to the 802.1AS time we could have a very difficult time trying to run any TSN features that are tied to the 802.1AS clock on top of PLCA. I’m not saying it can’t be done, but I am saying it is something we will need to study and understand the impact. In an ideal world we could sync the Beacon with 802.1AS time. Doing it the other way around would prove to be a bit of a challenge from the TSN side.
Again, thanks to all for a great meeting. It was certainly an eye opener for an 802.3 virgin like myself.