| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Brad, 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. Regards, John From: Brad Booth
[mailto:bbooth@xxxxxxxx] Dave, 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... Thanks, Brad From:
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, Dave Chalupsky From: Hi Mike,
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. Dan From: Mike
Dudek [mailto:Mike.Dudek@xxxxxxxx] Hi Dan 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. Regards Mike Dudek PMTS Standards & Technology JDS Uniphase CO 80027 Tel 303 530 3189 x7533. mike.dudek@xxxxxxxx From: Let me re-state one word of that
message. From: Hi Steve, 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. Dan |