Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Rick Pimpinella of Panduit is working to
subscribe to this reflector. In the mean time he asked me to share his
spectral width data from their assortment of transceiver samples. With
about twice the number of samples, and representation of eight manufacturers, it
validates the All this data is simply addressing the
potential availability of devices that could meet the proposed engineered link
spectral width. With ~40% of the samples passing the 0.30nm proposal, it
seems clear that the subset of 10GBASE-SR compliant parts is rather abundant. So
the industry is quite capable of supporting this proposal. Putting that aspect of the question aside
as resolved, the context of the discussion shifts from capability to
willingness. While I must agree that it would be
helpful (as well as the right thing to do) to give a reduced spectral width
transceiver a name to distinguish it from its minimally-compliant 10G-SR brethren,
it is not absolutely necessary to do so within the standard for this is not a
new PMD. Rather, is a completely compliant subset of the existing PMD. There
is no design change, nor a different parts list, technology, transmission
technique, or wavelength. The manufacturer simply sorts the parts from
existing production yield. It interoperates with its counterparts to the
full capability of the less-capable part. This interoperability aspect
would be clarified by granting a new name, but let’s look at the converse
first. There are plenty of examples of PMDs in
the market that do not appear in the standard. -SR-lite, -USR, and –ZR
are among the suffixes that come to mind. None of these need be compliant
to anything because they are proprietary. Every proprietary offer has no
assurance of interoperability, which is a cornerstone of why we develop
standards. Yet the market copes with all that, and the problems it brings
will not stop future proprietary offers. Now contrast those cases with that of the
engineered link proposal where the part remains completely compliant and
non-proprietary. The compliance aspect is powerful reason to give it a
nod in the standard. So what it is called can be defined in the
standard or left to the whims of proprietary offers. I propose that rather
than let this blossom into a whole range of new proprietary suffixes, to take
charge of it within the standard. If the remaining rub is really just
what to call it, let me propose some names: 10GBASE-SRX 10GBASE-SRE Here X stands for eXtended and E stands
for Enhanced. Both of these should ring well for those who like to think
of the definition of these suffixes in ways that relate to the customer rather
than technology. Placement in the last position is well suited, as that
location is often used for embellishments such as in –SR4, -SR10, -LX4. Now some of you will likely come back at
me with the argument that we don’t have a project to develop a new PMD or
we can’t do a new PMD under a maintenance activity. To both
arguments I say again that this is not a new PMD, it is a subset of an existing
PMD. We are operating under a project called 802.3bh with a scope encompassing
the entirety of the standard. No one has disputed the proposal based on
technical merit. The numbers are good. The changes are minimal.
And the benefit is harmony rather than possible confusion. Regards, Paul Kolesar From: Brad Booth
[mailto:bjbooth@xxxxxxxxx] Steve, The scenario you listed is not an apples-to-apples comparison, but
rather an apples-to-oranges comparison. I'm sure I don't need to remind you that the compliance point in an
Ethernet network is at the medium dependent interface (MDI). A customer that purchases a switch or server that has a port type
10GBASE-SR or 10GBASE-ER assumes that the device is compliant with the
specifications at the MDI. In the case of the ER channel, if the channel is
compliant with the specification - whether it is 30 km or an engineered 40 km
link - then the system will be interoperable. As for your concern, if the 500 m OM4 link was compliant to the channel
specifications at the MDI, then there would be no issue. From what has been
presented, the specification at the MDI looking into the PHY and into the
channel needs to be changed to permit a 500 m OM4 link. This is radically
different than what 10GBASE-ER requires, hence the inability to do an
apples-to-apples comparison. To try to require a tighter specification at the MDI while still
calling the port type 10GBASE-SR is misleading. As an industry, we would be
unable to guarantee interoperability to an end user that has purchase
10GBASE-SR optics for their devices and expect them to operate over 500 m of
OM4, because the only requirement for 10GBASE-SR is to be "minimally"
compliant with the specification at the MDI. Therefore, a new port type is
required for your proposal. To create an apple-to-apple comparison, don't touch the spectral width
of the 10GBASE-S PMD. If you can "engineer" the 500 m OM4 channel to
have the same performance specifications as a 400 m OM4 channel, then you would
be creating a system similar to what 10GBASE-ER does. This is just my take on it. Cheers, Brad On Tue, Aug 16, 2011 at 8:49 AM, Swanson, Steven E <SwansonSE@xxxxxxxxxxx> wrote: Dan, Thanks for the comment; I think this
subject will be discussed further in a future call but I would like to
understand the concern here. If someone releases a product tomorrow
that is 100%
compliant, but minimally meets the laser specs
for SR, then he can support a minimum of 400m per the standard. If someone releases a product tomorrow
that is 100%
compliant, but exceeds the minimum laser specs,
fiber specs and connector specs for SR by a defined amount, then he can
support a minimum of 500m per the standard (by definition, an engineered link). Contrast this with: If someone releases a product tomorrow
that is 100%
compliant, but minimally meets the single-mode
fiber specs for ER, then he can support a minimum of 30km per the
standard. If someone releases a product tomorrow
that is 100%
compliant, but exceeds the minimum single-mode
fiber specs for ER by a defined amount, then he can support a minimum
of 40km per the standard (by definition, an engineered link). But it is still 10GBASE-ER, right? Steve Steven E. Swanson t 828-901-5328
From: Dove,
Daniel [mailto:dan.dove@xxxxxx]
Hi Steve, I tend to agree with Brad. We cannot specify the reach based
upon empirical laser data. We must consider the specifications and assume that
somebody is going to release a product tomorrow that is 100% compliant, but
minimally meets the laser specs for SR. The goal of this maintenance effort should stick to confirmation
that existing SR optics (per spec) will support the reaches defined and I think
we have done that. We can debate about how much margin should be necessary as
this might allow a slight increase in reach, but 400m is a nice round number
and retaining some margin will increase confidence in passing the spec readily.
From: Brad Booth [mailto:bjbooth@xxxxxxxxx] Thanks Steve. BTW, you make
reference to last week's presentation. I remember reviewing it on the
conference call but was it ever uploaded? I'd like to be able to reference back
to it. As mentioned on
the call, the concern is lack of 100% coverage with available 10GBASE-S PMDs.
If only a subset of PMDs would satisfy the spectral width requirements for
achieving 500m reach, then that subset would require a new PMD name to
distinguish them as exceeding the 10GBASE-S requirements. I believe some felt
that we don't add a new PMD specification to 802.3 without a PAR that permits
use to do so. A new PMD is probably considered by many to be outside the scope
of the revision PAR. Cheers, Brad On Mon, Aug 15,
2011 at 12:56 PM, Swanson, Steven E <SwansonSE@xxxxxxxxxxx> wrote: Brad, I didn't do it for spectral width because I attached a plot of all
of the VCSEL spectral widths but here is the raw data:
So in the proposal we made last week, ~40% of the lasers would
support 500m with 1.1 dB margin; with a little less margin, I think .35nm will
work suggesting that ~78% of the lasers would support the proposal. Steven E. Swanson t 828-901-5328 From: Brad Booth [mailto:bjbooth@xxxxxxxxx] Steve, In bullet points
#2 and 3, you list the worst case wavelength and OMA power. Can you also do the
same for bullet point #1 for spectral width? Thanks, On Mon, Aug 15,
2011 at 10:23 AM, Swanson, Steven E <SwansonSE@xxxxxxxxxxx> wrote: Matt, I had an error in my calculation: 1. The average spectral width is 0.317 2. The average wavelength is 850.6; worst case 845.7 3. The average OMA power is -1.41; worst case -2.42 Using these numbers in the IEEE model yields 4.9 dB of margin
at 400m. Using these numbers in the IEEE model yields 2.6 dB of margin
at 550m. Steven E. Swanson t 828-901-5328 From: Swanson, Steven E [mailto:SwansonSE@xxxxxxxxxxx] Matt etal, I had our guys look at the VCSELs we have purchased on the open
market used in our test facilities; there are 70 transceivers from 6 different
manufacturers. 78% of the spectral widths are less than 0.35. The triple
trade-off numbers are as follows: 1. The average spectral width is 0.286 2. The average wavelength is 849.4; worst case 845.7 3. The average OMA power is -1.24; worst case -2.42 Using these numbers in the IEEE model yields 5.2 dB of margin at
400m. Using these numbers in the IEEE model yields 3.3 dB of margin at
550m. The more I look at this, I think we are being REALLY, REALLY conservative
in IEEE, maybe too much so; here is the distribution of spectral width: Steven E. Swanson t 828-901-5328 From: Matt Traverso (mattrave) [mailto:mattrave@xxxxxxxxx] Hello to the now
very active IEEE Maintenance reflector! As I mentioned
during my presentation at the IEEE plenary in July I would like to schedule a
few calls to follow up on the questions/comments raised during the meeting.
(see http://www.ieee802.org/3/maint/public/traverso_1_0711.pdf) My goal for these
calls per the discussion on the floor is to try to build more confidence in the
proposed reach value. I believe that there was broad consensus at the
meeting that (a) goal of specifying value is worthwhile,(b) theoretical
analysis was sound. I hope to confirm my perception at the first call
& discuss further justification for 400m reach. My intention is to
submit a comment by the comment deadline of Aug 26th. Call timing: Wednesday Aug
10th, 10 – 11:30 am PT Wednesday Aug 17th
, 10 – 11:30 am PT Meeting login
details below best regards --matt traverso -+-----+-----+-----+-----+-----+-----+-----+-----+- Meeting Number:
203 920 382 Meeting Password:
OM4 ------------------------------------------------------- To start this
meeting ------------------------------------------------------- 1. Go to https://cisco.webex.com/cisco/j.php?J=203920382&PW=NNjg0OTljYThj 2. Log in to your
account. 3. Click
"Start Now". 4. Follow the
instructions that appear on your screen. ---------------------------------------------------------------- ALERT:Toll-Free
Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll
free numbers are: (866)
432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP
area. Please dial the
local access number for your area from the list below: - San
Jose/Milpitas (408) area: 525-6800 - RTP (919)
area: 392-3330 -------------------------------------------------------
To join the
teleconference only -------------------------------------------------------
1. Dial into Cisco
WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html
2. Follow the
prompts to enter the Meeting Number (listed above) or Access Code followed by
the # sign. US/Canada: +1.866.432.9903 United
Kingdom: +44.20.8824.0117 CCM:+14085256800x203920382# |
Attachment:
Panduit Spectral Width Data.pdf
Description: Panduit Spectral Width Data.pdf