(as individual) Yeah, I think we are talking past each other. I’m trying to see whether there is another spec needed, so that IF someone (even me) makes a comment, it is directed towards solving the problem and suggests a solution.
My suggestion on Philips’ questions was to look at all the relevant parts of the 802.3 specification (as modified by 802.3cg) to figure out what requirements on the behavior are there). At least some of the answers are in clause 22, but
maybe not all.
Hopefully we agree that the specification needs to identify the behavior completely.
If a commenter identifies something missing in the behavioral specification, the group needs that information.
Further, I believe that the goal is to fully specify the behavior without specifying the implementation. (I hope we agree on that as well)
Focusing on the questions – we should not be saying exactly how they are detected (what circuitry does what) but rather what must be reliably detected and make sure that the behavior of the PHY when that stimulus occurs is clear. Glitching
of the CRS signal seems clear from Clause 22. Timing of the CRS relative to energy at the MDI may not be and may need an additional specification. I’m still looking into it, but if a commenter agrees, they may wish to comment and suggest a value/specification
to fill in. Some background below to help.
Timing requirements are a bit variable in 802.3 PHYs - Clause 8.2.1.3 (10BASE5 Collision detect requirements, since there is no CRS on the clause 8, this gives CS0 timing of 17 to 29 bit times from the MDI to the AUI) or Table 24-2 (100BASE-X,
half duplex, assert up to 20 BT, deassert between 13 & 24 BT) are examples of specifying this timing. These clauses don’t apply to us, but I think it would be a good idea for implementers to consider what the right values would be for 10BASE-T1S half duplex.
Clause 147.11 (Delay constraints) may be the right place to put this. right now it specifies 4 usec (40 BT at 10Mbps) for a packet at the MDI to the assertion of RX_DV. I haven’t yet dug deep enough to know how much of a delay in CRS/COL assertion is tolerable,
but the existence proof of 10BASE5 says up to 29BT is at least compatible.
-george
From: Yong Kim <yongkim.mail@xxxxxxxxx>
Sent: Friday, February 08, 2019 10:00 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] Feasibility of 147.3.5 Collision detection
:-) We keep talking past each other.
Your point -- 20 BT WRT to BEACON is sufficient.
My point -- ONLY reference to collision detect is (added text D2.2->D2.3) data error, and 256 bit times, and "implementation dependent is left somewhere I believe."
Your conclusion -- i don't see a problem.
My conclusion -- There is no detail in CL147 to even begin answer the question Philip asked. No detail to base the analysis. My rationale for commenting on this on current ballot and inviting anyone
else who feel the same way to do the same.
Ditto for CL22 in similar vain. Probably no need to repeat.
Yong Kim, affiliation: NIO
(seems we have a lot of reflector delay here)
Not sure what you’re getting it. the questions I heard related to:
-
The duration of a beacon – is that sufficient to be able to detect a collision? I stated that 20BT at that amplitude should be sufficient. You asked where the 20BT comes from. It comes from the beacon timer, which regulates how long the phy stays in the
‘send beacon’ state and hence the length of the beacon on the line.
-
The references with respect to clause 22 were in regards to specifically the question regarding glitching of the CRS signal (“Does the CRS need to be asserted during the entire time that the drivers are driving or is
the CRS allowed to glitch?”) Clause 22 states the requirements for CRS assertion. A phy must meet it. how id does so is implementation dependent.
I’m trying here (as an individual) to help Philip with his questions and see if these answer them. If you have help for him in answering his questions, that would be constructive.
-george
From: Yong Kim <yongkim.mail@xxxxxxxxx>
Sent: Friday, February 08, 2019 9:50 AM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] Feasibility of 147.3.5 Collision detection
20BT reference to beacon timer is correct statement, but not at all relevant to collision detection time that was/is the topic of discussion.
WRT to CRS in CL22 -- the shall statements DIRECT all PHYs that connects to CL22 to meet that requirements. Again your assertion is correct
statement but not relevant to HOW CL147 assures this requirement so clearly stated in CL22. And to be absolutely clear, each and every PHY clauses that use CL22 shall assure *HOW* those shalls are met. WRT to CL147, we have unresolved negative comments
dating back to pre-WG ballot, and initial working group ballot that have not been satisfied.
The above -- again -- all my opinion only, except for the reference to unresolved comments (that is a fact).
Yong Kim, affiliation: NIO
Thank you for the reminder – speaking as an individual.
(again as an individual) I beg to differ on the content of the draft and on clause 22 -
The 20 BT reference is at 148.4.5.4, it is the duration of “beacon_timer” which times the duration of the BEACON signal.
The definition of what a PHY needs to detect for a collision is the first thing at 147.3.5 “When operating in half-duplex mode, the 10BASE-T1S PHY
shall detect when a transmission initiated locally results in a corrupted signal at the MDI as a collision.”
The requirements for assertion of CRS are found in 22.2.2.11. You are correct that additional requirements are in clause 147, but the clause 22 requirements
remain. It seems pretty clear here that they are not allowed to glitch, but is required to be asserted when the medium is nonidle… I would start there and then determine whether something additional is needed:
CRS shall be asserted by the PHY when either the transmit or receive medium is nonidle. CRS shall be
deasserted by the PHY when both the transmit and receive media are idle. The PHY shall ensure that CRS
remains asserted throughout the duration of a collision condition.
CRS is not required to transition synchronously with respect to either the TX_CLK or the RX_CLK.
You might suggest something more is needed, to fully specify the behavior, but specifying a particular implementation is generally a bad idea, and simply describing one doesn’t
add any missing requirements.
-george
From: Yong Kim <yongkim.mail@xxxxxxxxx>
Sent: Thursday, February 07, 2019 5:53 PM
To: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Cc: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_10SPE] Feasibility of 147.3.5 Collision detection
Thanks. It would be helpful (at least to me) if you were to clarify each of the points whether you are speaking as the chair or as a member.
Just sharing my opinion. WRT to collision detection. THERE IS NO SPECIFICATION other than "implementation dependent". Some text were
added between D2.2 and D2.3 something about data error/corruptions == collision but with little detail. THIS is the only standard text we go by and review. I was careful to say that IF Hongming's text (brief) were in the draft THEN people could evaluate/analyze
(a lot work to be down downstream). But it is not.
And more of my opinion. WRT to Philip's email, 256 bit is in the draft text. ~20 bit reference you made is not. Also his question deals
w/ 147 specification, not CL22. He wrote "..in 147.3.5 b) it is stated that a third PHY shall assert CRS in case two or more stations cause a collision. Does the CRS need to be asserted during the entire time that the drivers are driving or is the CRS allowed
to glitch? What is the maximum allowed delay from reaching differential zero on the MDI until CRS is deasserted at the MII? What is the minimum required time from driving the differential pair to +-1 until CRS shall be asserted?..."
Yong Kim, affiliation: NIO
Hongming – thank you for your answers. It’s clear you’ve given some thought to how to build this.
The insertion loss of the mixing segment is specified in 147.8.1 (which references 147.7.1). The loss at midband is specified to be less than 2.6 dB. In voltage terms that says
that the amplitude of the signal from a far end node will be 75% of the amplitude (at 10 MHz) than what is transmitted near-end. I’d think that kind of variation would be detectable. Remember, we have a scrambler, which ensures that transmitted bit sequences
are unique with high probability. That separates this from early Ethernet’s challenges.
If you don’t agree, please provide the analysis to show otherwise. And not just that a detection COULD be missed – we can all make broken designs. Instead, I’d want to see analysis
that a device cannot be made to provide a reliable detection (because others believe it can).
Also, remember, the standard is not a tutorial, it is an interoperability specification. The detection method is local to a node, and is not an interoperability specification.
On process, I’d like to point out that questions, while welcome, and a good use of the reflector, are a different thing than either a problem or a proper ballot comment. Proper
ballot comments come when a commenter thinks there is a problem. To convince others, the commenter needs to provide analysis showing the problem and a potential remedy. Having questions isn’t enough – you need to convince people there is a problem, AND the
commenter has responsibility to propose a remedy. If you think something CANNOT be accomplished, please show that – you must convince others why the specification is not implementable, and not just say “show me how”.
Additionally, having read Philip’s email, I honestly take it as some questions, not a comment.
I refer Philip to Clause 22, where the behavior or CRS and COL are specified as signals. Requirements for asserting and holding CRS are found there, and not in the 802.3cg draft.
I wouldn’t take the 256 bit time assertion of COL as the detection time allowed. That specification is simply on the time to hold the COL signal, not the detection window. Collisions
need to be detected in less time than that – I would think a 20 bit sequence of corrupted transmission symbols (2usec) would be enough to detect.
I’d add that when all nodes have PLCA implemented and enabled, these signals do not interfere with data frames on the medium.
The way I understand it, if a node either without PLCA enabled or without PLCA implemented is present on the mixing segment attempts to transmit a frame simultaneously with one
of these control signals, that (non-PLCA) PHY would detect the collision and signal its MAC appropriately to control the transmission of its data frame, as already specified in clause 147. The PHY transmitting the PLCA signal’s behavior is specified by the
Figure 148-3 (PLCA Control state diagram). (basically the beacon transmission stops as the PHY goes to the RECOVER state due to CRS being asserted).
Piergiorgio may have more explanation to follow.
-george
To unsubscribe from the STDS-802-3-10SPE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
To unsubscribe from the STDS-802-3-10SPE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
To unsubscribe from the STDS-802-3-10SPE list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
To unsubscribe from the STDS-802-3-10SPE list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-10SPE&A=1
|