Ali,
The question is not "How" to do it. The question is "What" to do.
The data will show us whether a single PMD capable of being used in low latency applications, or long reach applications can produce a successful market potential.
A Venn diagram might be more useful to explain this, but I thought I did OK with my flow chart.
If the data points to CASE-A, I would support having two separate PMDs.
If the data points to CASE-B, I would support having a single PMD.
But the DATA needs to be produced and analyzed.
Regards,
On 2/18/15 3:34 PM, Ali Ghiasi wrote:
The question is not "How" to do it. The question is "What" to do.
The data will show us whether a single PMD capable of being used in low latency applications, or long reach applications can produce a successful market potential.
A Venn diagram might be more useful to explain this, but I thought I did OK with my flow chart.
If the data points to CASE-A, I would support having two separate PMDs.
If the data points to CASE-B, I would support having a single PMD.
But the DATA needs to be produced and analyzed.
Regards,
On 2/18/15 3:34 PM, Ali Ghiasi wrote:
Dan/Brad
Here is an approach to make -S and -L CR standards interoperable by creating super-set PMD but still address potential low latency applications:
o. Host- Baseline capability RS-FEC- Optionally host my implement and/or support CL74 or no FEC- Mechanism to advertise what is supported under system management- All host must support the maximum reach and both -S and -L cable reaches
o. Cables- CR-S any cables shorter 2-3 m (with xyz loss) if plugged into host the management may invoke CL74 or no FEC- CR-L any cable longer >2-3 m (with loss >xyz) if plugged into host will use the default RS-FEC
With above approach we are not creating two PMDs, single common host is created but cables are labeled -S and -L depending on the cable length.
On Feb 18, 2015, at 2:44 PM, Dan Dove <dan.dove@xxxxxxxxxxxxxxxxxx> wrote:
Hi Brad,
I think the counter argument goes like this...
If you have only a single instance in the market called "25GBASE-CR", and it allows someone to build a product that supports only 3m cables (does not advertise 5m capability), a customer will purchase a bunch of switches, 5m cables, 3m cables, and servers, all from different suppliers, plug them all together..double checking to make sure they are all "25GBASE-CR", then discover that some combinations of products don't talk to each other.
They scratch their heads, look for details on what the common modes of failure are, then come to a conclusion that only supplier X switches, and supplier Z NICs, and 5m cables are problematic. supplier Y's stuff is working with all cables. They go to supplier X and supplier Z, explain their problem, and those suppliers say "We are compliant to the standard, but don't support 5m cables".
What!?!?
"Oh ya, the RS-FEC required to support 5m cables was optional, and because it added X% to the die, our chip supplier left it out of the design to save cost and power...but we are still compliant!"
Clearly that doesn't work out well.
I see the challenge as this;
If there is no significant cost/power/die/etc impact of supporting 5m over 3m, then we should have a single "25GBASE-CR" standard and mandate support for all cable lengths. Deciding not to support RS-FEC would be an option for applications with shorter cables to reduce latency, but only an option to use, not an option to include in the implementation.
If there IS a significant cost/power/die/etc impact of supporting 5m over 3m, we have to consider whether that additional cost/power/die/etc will burden markets that want optimum cost/power/die/etc and don't need 5m. If yes, then we should have two specs (CR-L and CR-S) to allow market optimization. If not, then we force the market to accept one-size-fits-all.
<jfajahhg.png>
To be frank, I have no preference in where we end up, but do wish to see the key questions answered with sufficient data to make the right decision.
On 2/18/15 2:05 PM, Brad Booth wrote:
I want to say thanks to Jeff for listing some of the options the task force can consider for auto-negotiation. All the options presented by Jeff and Eric could be specified in the draft standard.
I'd like to provide some clarification on my opposition to using -L and -S options. The primary concern I have is reflected in statements some people have made in justifying the -L and -S options. In my humble opinion, the -L and -S options push the draft standard towards being an implementation specification and permitting folks to market their devices as either -L or -S compliant. This could create a potential bifurcation of the market; hence my request for those supporting a -L and -S option to provide information on the broad market potential.
As an example of auto-negotiation not used in as an implementation specification, let's look at 1G. There is a load of information that is exchanged during auto-negotiation. In 1000BASE-X, AN exchanges pause and duplex information. In 1000BASE-T, even more information is exchanged like master-slave, etc. What is important to understand in the operation of these devices, a management entity assists with the establishment of the link. If a 1000BASE-SX local device only indicates half duplex and its 1000BASE-SX link partner only indicates full duplex, then AN will signal to the management entity that the link cannot be established. The half duplex device is not labeled a 1000BASE-SX-H device and the other is not labeled a 1000BASE-SX-F device; those labels would be an implementation option. The management entity could decide that either these devices can never talk, or that auto-negotiation needs to be restarted with a different exchange of capabilities.
That's what worries me about using -L and -S in AN and tying it to the port type or maximum cable assembly length. That's an implementation. And honestly, -L and -S starts to sound like marketing terms and not technically justified terms. Permitting AN to exchange capabilities and preferred modes of operation (no -L or -S option) really does provide the greatest flexibility for implementations in the market.
Thanks,
Brad
