|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Please see below.
Please note that my comments are in regards to the capabilities of the architecture, and I am not siding with any proposals.
From: Mike Dudek
I agree that our job in the standards is not to define implementations, but to set interface specifications. I’ve discussed this in the ad hocs but it looks as though it’s time to bring it to the reflector. The issue here is whether the TP2 and TP3 specs are set to enable 100m OM3 only or 150m OM3 and 250m OM4 fiber. In order for the CDR in module to go the longer distance the TP2 and/or TP3 specifications need to be tightened. (otherwise vendors can put the CDR in the module, and relax other module performance, still meet the 100m TP2 and TP3 specs and will only go 100m).
JD > This is related to the use of the same PMD sublayer. So if we assume that, and someone develops a nAUI interface to the module, then shouldn’t the jitter at TP2 / TP3 as a result be tightened up? These tightened #’s can be addressed in an informative annex
It is possible to set the TP2 and TP3 specs in a generic manner that will achieve the longer reach. These are the optical specs. The electrical specs on the module inputs and outputs can be either
1 the PMD service interface for optics,
2 the PMD service interface for copper (may be the same or different to the optics version, I think this is still a TBD),
If people are using XLAUI/CAUI then a CDR is very likely needed in the module.
JD > Please note that retiming is necessary at both ends of the nAUI, so if the module has a nAUI interface, then it will need retimers in it.
If people are using the PMD service interface for optics then it is possible to either include the CDR in the module or improve other aspects of a limiting part to achieve the TP2 and TP3 specs.
If people are using the PMD service interface for copper the host will include EDC and a linear module could meet the TP2 and TP3 specs.
JD > understood, but even if they were to do these implementations, I believe the implementation of a module with a nAUI interface would still result in better jitter #’s at TP2 / TP3. This is my point – the architecture enables such implementations.l
IE by appropriate test methods and spec setting it is possible to achieve the longer distance without picking an implementation method.
Note that this still leaves the question of whether longer distance TP2 and TP3 specs should be the only normative specs; there would be two sets of normative specs; or the longer distance specs would be in an informative annex.
From: John DAmbrosia
Thank you for bringing up these points. During the course of this project, I have emphasized that we are developing an architecture that should enable as many implementations as possible, and not writing an implementation specification. You have hit the nail on the head with your points.
The base proposal for the BASE-SR physical layer specifications is based on the jitter associated with a non-retimed interface to achieve 100m. There has been general discussion that adding retimers to a BASE-SR module would then extend reach. Per http://www.ieee802.org/3/ba/public/AdHoc/MMF-Reach/Comparisons_xr_01_0722.xls, and column D (latchman_xr_01_0508), CDR’s on one side would extend the reach to 168m and CDRs on both sides would be 208m (both #’s are based on OM3 fiber).
So if we review the adopted architecture proposal, and consider implementations for different reaches, what do we find?
The thing is that we approved an architecture with the XLAUI / CAUI optional interface. This is a retimed interface. So it seems to me that we have developed an architecture where either implementation using the same PMD sublayer could be developed, i.e. a PPI (non-retimed interface) to a module or a XLAUI / CAUI (retimed interface) to a module.
Thinking about how to implement in the spec - The minimum guaranteed interoperability would be 100m, which is in the current specification. An informative annex could then go into engineered links for 150 and 200m, based on the use of modules with either the PPI or the XLAUI / CAUI interfaces. Pardon the choice of words, but I think this would be rather informative anyway, as the spec already enables both types of implementations.
Based on this, it would seem that the TF has been successful in developing an architecture where implementations could be developed to support either reach.
From: Brad Booth
I agree. A 5% cost adder seems reasonable for a 17% increase in broad market potential.
I do wonder if part of the problem is the compliance points TP0, TP1, TP1a, TP4, TP4a and TP5. In past efforts such as 802.3z and 802.3ae, these compliance points have been left up to MSAs and only TP2 and TP3 were of concern. Now the task force is dealing with such issues as modules and the cost impact of various implementations. IMHO, IEEE 802.3 was trying to avoid writing implementation specifications and was focused on compliance specifications. Could it be that these compliance points are causing the task force some heartache because it results in an implementation specification?
Just food for thought...
Chalupsky, David [mailto:david.chalupsky@xxxxxxxxx]
The 20% cost premium applies to only one of our proposed XR alternatives.
According to the alternatives spreadsheet (Comparisons_xr_01_0708.xls) the CDR option adds only 5% module cost premium over the base proposal and provides reach of 168m to 251m (across the OM3/4, one-sided/two-sided matrix).
I’m struggling to keep up with the conversation here – but I believe that the 5% alternative addresses the same problem as the 20% alternative, right?
On that assumption I will rephrase Dan’s non-rhetorical question to address a 5% cost adder for 17% increase in coverage:
If I have the choice between:
A) carry two product SKUs: 100m and 150m, with 5% Bill of Material cost delta on the 150m product; or
B) carry only the 150m product
I would accept option B & use only the 150m module even though I know that most of my customers will use it at <100m.
By considering only the bill of material of the module we are missing two aspects of the big picture on cost.
1) Carrying multiple product SKUs through design, validation, manufacture, customer qualification, customer confusion, etc. adds cost.
Regardless of whether 802.3ba adds a second objective, if the module supplier base develops two different module solutions for 100 & 150m, then the 100m solution will carry an intangible cost burden and the desired 0% cost adder for 100m will not be achieved anyway.
2) The module is not the whole solution. The CDR module solution does not add cost to the host. Thus a 5% increase in module cost is less than 5% increase in the total cost of the switch plus modules.
I appreciate that the task force is learning from the history of 10GBASE-SR: that over-specifying the solution had a long term cost impact.
However, we should take away another lesson from 10Gbit: that providing too many options confuses the customers & slows adoption.
I strongly urge the task force to provide a single solution for parallel MMF. I believe that it’s worth a 5% cost adder to the module to achieve that.
I really have no personal (or commercial) reason to prefer the CDR option. I’m just looking at the 5% figure in the spreadsheet & wondering why this isn’t a no-brainer.
Thanks for your time,
Assuming we make the decision that we want to stick with the "standard" model at 100m to keep those customers we would lose by adding cost, does the IEEE standardize a 150m solution or do we let the market solve that problem on its own?
This is not a rhetorical question, although it might appear to be.
Can someone provide any insight on the sensitivity of the market to an additional cost of 20% for every 100m link to satisfy the additional reach?
If the market is insensitive to cost (on this scale) then perhaps the additional reach is justified. If the market is going to be sensitive to that differential cost, then the question falls back to whether the IEEE wants to do a 150m spec or leave it to a market-defned solution.
Of course if we don’t increase the cost of the basic Grade A model and have a Grade B version of the same part for extra reach with the Grade B version being loaded with any additional costs of handling two product codes and any additional testing, then we shouldn’t lose any customers.
PMTS Standards & Technology
Tel 303 530 3189 x7533.
Let me re-state one word of that message.
Yes that helped a lot. I hope the others on the list are not irritated by my request for repetition of the data.
Given the data, it truly is a challenging issue. I see a 20% premium for a 17% increase in coverage.
This means the confidence in the numbers is exceptionally important and assuming they are accurate, a judgement call by the committee on whether or not a 17% increase in port coverage justifies the 20% increase in cost.
This is important because if you increase the *COST* of a solution by 20%, you may decrease the number of customers who are willing to buy it by more than 20%. Thus, in the overall mix, it might turn out to satisfy less customers overall.
Its a pretty challenging judgement call IMHO.
Thanks for providing the data.