|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Regarding the original email, some tentative thoughts:
If the beacon cycle can drift with respect to the 1AS clock, then the timing of the opportunity to transmit (TXOP) can drift, even if the transmissions from each node are internally scheduled to high accuracy.
The existing proposal suggests a TS_TIMER and BEACON of 1.6 us. With 8 nodes, we may have an immediate opportunity to transmit, or we may just miss out opportunity and have to wait 7 * TS_TIMER + BEACON = 12.8 us. Considering a 64 byte frame (512 bits) plus 64 bits preamble and SFD, we have 57.6 us for the frame. TSN slots could be scheduled as close as 70.4 us to account for this worst case latency at each transmission. This is 82% efficiency. My experience is that minimal IP-based packets are closer to 100 bytes (864 bits with overhead), giving 85% efficiency.
The PHY latency must also be considered, as well as whether it could be compensated. It may lower the efficiency, but can still be accounted for as long as there is a worst case.
Another point is that the Beacon format needs to be evaluated. Maybe it is longer for robustness or some other reason. This would also lower the efficiency.
From a 1AS viewpoint, it does seem there is benefit in synchronizing the beacon, but I’m not sure how that is done. Maybe the answer is that this protocol (PLCAI – implicit versus explicit) can be turned on and off in the PHY.
David D. Brandt
802.1AS time runs independent of the 802.3 timestamps. Those timestamps help us measure elapsed time of the local clock related to elapsed time of the 802.1AS clock. Often times that “local clock” happens to be directly related to the Ethernet bit time clock since they run off the same 25MHz (Fast Ethernet) or 125MHz (Gigabit) crystal.
However, if the 802.1AS Grand Master is not on the same network segment you will find that it runs at a rate that is not a direct ratio to the local 25/125MHz crystal.
It looks like a more focused 802.3cg PLCA + TSSI vs 802.1AS timing presentation may be useful in the near future.
I always believe that anything can be solved if we just have enough time to think about it.
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.