| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
The alternative option is, instead of calling this “latency improvement” we could call this as “scheduling improvement” and one of the benefit could be latency improvement depending up on the application. Thx, From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
It would be nice to get some consensus on a minimum latency improvement, but I really don’t think we have seen material that allows us to set that goal. It’s also not clear that such a measure would be useful
given random traffic and node configurations. However, contributions would be helpful on that. I do not think we can limit traffic size (frames or otherwise), but we can present analyses of techniques under specific conditions in the task force. With objectives
you aren’t really asking the working group in general to measure the latency – only to look that the work has been done. Presenting material supporting changes in the task force is generally sufficient. The issue of what happens when you mix nodes with E-PLCA enabled and those without it on the same mixing segment is likewise one of analysis and definition. How the two interact needs to be a subject of discussion
in the task force. It needs contributions and analysis. I think what we need to get consensus on is whether we merely support backwards compatibility (fall-back to E-PLCA not enabled if there is even on non-E-PLCA node), or whether we have a graceful degradation.
A similar statement applies to D-PLCA. Not breaking the existing protocol can be accomplished as simply as signaling & detecting whether all nodes have the new functionality enabled, and, if not, disabling the new functionality. That isn’t my preferred path,
but it is a path to compatibility. Coexistence with graceful degradation of the new functionality’s benefits would be preferable. Again, as we get into proposals, we will need analysis of these effect. Regarding “what people expect”. I fear you are confusing marketing to the general public with objectives as a formal part of the standards process. Sometimes objectives are used that way, but when something
is confusing, it is often useful to prepare a ‘tutorial presentation’ at or near the time of WG ballot to describe what the standard does. That’s better than trying to put forward complex objectives statements. George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 From: Subramaniam Aravindhan <Subramaniam.Aravindhan@xxxxxxxxxxxx>
Thanks George for pointing to some of the reference materials. On the objective
#4 of 802.3da
Thx, From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
Arvindh – you need to understand what 802.3 objectives are. Usually they are simple bullet points, not paragraphs with lots of caveats. They generally aren’t an ordered list. You don’t need caveats, and detail should be light - we aren’t writing the standard here. You don’t say How you’re going to do things in the objectives – you say What the standard is going to achieve. For
example, PLCA was never actually an objective in itself. A multidrop PHY for automotive & industrial network environments was the objective, along with the speed (10 Mbps at the MAC/PLS service interface), reach, and rate. The objectives are our commitment as a task force (when we become one) to the members of the working group on the minimum we are going to address. For example, for a PHY they are bit rate, error rate, reach
and medium. They need to be voted on by the members of the working group – so they shouldn’t be too deep inside the development.
They need to be at the level where when a working group member outside of the task force reads the standard, and can then make a judgement and base a vote on it – Voting could be on the WG ballot draft (whether
it met the objectives), or even as simple as whether we are ‘technically complete’ so that we can us proceed to WG ballot. In short, restrictions and caveats are assumed. A “PHY project” objectives may not be a good example for us, although we can use some of 802.3da as a model. 802.3da had a number of PHY objectives but also had: Specify an optional PLCA node ID allocation method And Support optional Time Synchronization Service Interface (TSSI). These are high-level, don’t say how we are going to do it, or even what the caveats are on usage. Another good example to look at would be the 802.3dt (Ethernet Metadata Services) objectives. They have a pretty high level project which interacts with things outside our scope, similar to EPLCA. Their
key functional objective is in one line: “ Define optional per-packet and packet-independent metadata services and associated modifications to the physical layers using the:” (and then with a list of the supported PCS’s intended). Regarding PHY support, that is still needed (it could be replaced with a more detailed statement about the Clause 22 MII, as in 802.3-2022, but that’s not really what we are aiming at…). Consider that you
are modifying the RS (which is PLCA). That includes the MII and interface to the PHY. If we were, for example, to invent a new MII encoding to be used, the existing PHY clauses would not understand how to encode that. We wouldn’t be compatible with the PHYs
as specified. Therefore, I think we need the statement about compatibility with the PHYs. Backward compatibility with CSMA/CD and PLCA is with regards to the MAC and to the other nodes on the mixing segment. Compatibility with the PHYs is on the local station, between the RS and the PHY. It’s
just a different thing. Again, I hope this helps, but frankly, you’re overcomplicating this – and looking at what is needed here, and has been done, is not only useful, it’s an essential first step. George Zimmerman, Ph.D. President & Principal CME Consulting, Inc. Experts in Advanced PHYsical Communications 310-920-3860 From: Subramaniam Aravindhan <Subramaniam.Aravindhan@xxxxxxxxxxxx>
Hi Yong, and all, One recommendation to list the EPLCA first and backward compatibility later in the list.
Since we are supporting backward compatibility with CSMA/CD and PLCA, there is no explicit need to specify “Clause 147 & 188 multidrop PHYs” now. If we are committing to have changes only in 148 and no changes in 147 and 188, then we
could word it as “Only changes in Clause 148 and no changes in Clause 147 and Clause 188”. Thx, From: George Zimmerman <george@xxxxxxxxxxxxxxxxxxxx>
I’m starting this as a new thread so people can keep it clear on the discussion. Regarding the objectives, I think at least Arvind and I agree that we need some clarification. Support interoperability with Clause 147 & 188 multidrop PHYs: I think that in light of the 802.3 definition of PHY, rather than the “chip” definition of PHY (which can be different for any implementer) “Support interoperability with Clause 147
& 188 multidrop PHYs” is OK. PHY means the PCS & PMA in IEEE Std 802.3, and that’s the audience – the working group. However, in the other basic objectives, we have some work to do: Preserve PLCA method: I agree we need something better than “Preserve PLCA method” Objectives need to be clear as to what we mean. There are a variety of meanings I could take from this. Less is more
in objectives – we don’t want to write how the spec will come out, but looking at what you have, I think we mean:
I suspect that we agree that this means something like your Backward compatible with PLCA; but EPLCA latency predictability will not be guaranteed… because interoperability doesn’t
mean the benefits of the enhanced technique are maintained. Most understand that performance goes to the lowest level… DPLCA: I think we need to discuss D-PLCA. I would suggest:
Given that D-PLCA can have a set of statically assigned ID’s we ought to be able to set up a working performance regime which doesn’t completely fail when E-PLCA is enabled on some nodes and D-PLCA
nodes are on the mixing segment. Whether we can come up with a way to preserve E-PLCA benefits with D-PLCA active is an item for work. Not sure we need to decide that now, but we shouldn’t have the network crash if you have both, and an objective to “Preserve
interoperability” does that. Specify PLCA selection service client to be used by upper layer: I think we need a little wordsmithing here. I believe we specify a client interface (primitives) to communicate priorities. This way implementers, and specifications
like 802.1 can control the mechanisms of PLCA to do this. We haven’t defined what the client actually is, and the innards are probably out of scope for IEEE Std 802.3. We also can’t define who uses it – that is above the scope of 802.3 (we can give them
the tools, but we can’t make them use them). Hence, I’d suggest we focus on the interfaces to parts that are actually in 802.3:
When we know more about the PLCA priority service client we might be able to say more here. It might be best to wait a little on this objective. -george To unsubscribe from the STDS-802-3-EPLCA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1 To unsubscribe from the STDS-802-3-EPLCA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1 To unsubscribe from the STDS-802-3-EPLCA list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1 To unsubscribe from the STDS-802-3-EPLCA list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPLCA&A=1 |