Re: [HSSG] BER Objective
Steve,
Would you want to make the FEC part of the PHY or include it in the MAC layer?
Regards,
Menachem
Menachem Abraham
Columbus Advisors
-----Original Message-----
From: "Trowbridge, Stephen J (Steve)" <sjtrowbridge@xxxxxxxxxx>
Date: Tue, 29 Aug 2006 17:23:48
To:STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] BER Objective
Mike,
I fully agree. I think we would be reckless to be building an interface
at this kind of bitrate that wasn't FEC capable. Certainly all of the
transport interfaces from 2.5Gb/s and higher are capable of FEC.
You can always switch it off if:
(a) You are running a very short link that is so far within the link
budget that you know the BER performance will be much better than
required by the spec; or
(b) You have an application where latency is more important than BER
performance.
As mentioned before, for anything going over a WAN or (other) transport
network, the propagation delay is much larger than the FEC computation
delay.
Regards,
Steve
-----Original Message-----
From: Mike Bennett [mailto:mjbennett@xxxxxxx]
Sent: Tuesday, August 29, 2006 3:57 PM
To: STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
Subject: Re: [HSSG] BER Objective
Roger,
I don't think PHY latency would be an issue for transport providers,
since the propagation delay would dominate. Latency requirements will
differ depending on the application.
Mike
Roger Merel wrote:
>
> Unfortunately FEC is not an option as these applications are even more
> sensitive to being low latency. FEC adds latency.
>
> ----------------------------------------------------------------------
> --
>
> *From:* Mike Dudek [mailto:mike.dudek@xxxxxxxxxxxxx]
> *Sent:* Tuesday, August 29, 2006 2:36 PM
> *To:* STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> *Subject:* Re: [HSSG] BER Objective
>
> Am I being naive here, or could the applications that require the
> super low error rates include some FEC, without burdening all the
> physical layer applications with a requirement for extremely low error
> rate. Although present applications may be expected to be the high end
> users that require the extremely low error rates, if we have broad
> market potential that segment of the market is going to drop in
> percentage in the future. Other standards have included FEC why not
> this one? (10GEPON is looking at pretty strong FEC).
>
> Regards,
>
> Mike Dudek
> Director Transceiver Engineering
> Picolight Inc
> 1480 Arthur Avenue
> Louisville
> CO 80027
> Tel 303 530 3189 x7533.
> mike.dudek@xxxxxxxxxxxxx
>
> ----------------------------------------------------------------------
> --
>
> *From:* Trowbridge, Stephen J (Steve) [mailto:sjtrowbridge@xxxxxxxxxx]
> *Sent:* Tuesday, August 29, 2006 2:50 PM
> *To:* STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> *Subject:* Re: [HSSG] BER Objective
>
> Jungu,
>
> Looking further into the thread, I think there are at least two
> separate questions:
>
> - What BER level is feasible to test/verify? Can it be tested
> directly, or only through extrapolation?
>
> - What BER is needed for the service?
>
> I had reacted initially to the statement about errors being "few and
> far between" and the discussion about lengthy tests being required,
> almost in the same breath as proposing BER of 10^-10, which made no
sense.
>
> Other discussion seems to revolve around what this BER is good enough
> for the service. From the discussion, I agree that if your 100 Gbit/s
> is an aggregate of a huge number of much smaller flows, we can
> consider BER in terms of the percentage of corrupted packets and
> required retransmissions and not have to strive for lower BER as we go
> to higher bitrates. But if the interface is used because the customer
> needs a small number (perhaps only one, in a supercomputer
> environment) of very large flows and stopping to retransmit might idle
> some very large processors, this is a different situation entirely.
>
> Probably good to try to separate the two questions above for the
> discussion.
>
> Regards,
>
> Steve
>
>
> ----------------------------------------------------------------------
> --
>
> *From:* OJHA,JUGNU [mailto:jugnu.ojha@xxxxxxxxxxxxx]
> *Sent:* Tuesday, August 29, 2006 2:14 PM
> *To:* Trowbridge, Stephen J (Steve);
STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> *Subject:* RE: [HSSG] BER Objective
>
> Steven,
>
> I was trying to understand whether 1 error per second is a lot
> worse from a performance point of view than 1 error every ten
> seconds. Your point about the extra test time is valid for the
> foreseeable future, where these interfaces are only used for
> high-end applications.
>
> Regards,
>
> Jugnu
>
>
> ----------------------------------------------------------------------
> --
>
> *From:* Trowbridge, Stephen J (Steve)
> [mailto:sjtrowbridge@xxxxxxxxxx]
> *Sent:* Tuesday, August 29, 2006 1:11 PM
> *To:* OJHA,JUGNU; STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> *Subject:* RE: [HSSG] BER Objective
>
> Jungu,
>
> I'm confused. I see a proposal to use a BER requirement of 10^-10
> and these words about errors being "few and far between", yet 100
> Gbit/s is 10^11 bits/s. An average of 10 errors per second doesn't
> meet my idea of "few and far between", and I doubt this would be
> acceptable to most users who will pay the kind of money this kind
> of interface is likely to cost.
>
> I am curious whether a really high end interface like this makes a
> lengthier test more feasible (i.e., you couldn't afford to do a 10
> minute test on an interface you expected to sell for $10. But for
> an infrastructure interface like this one, perhaps some extra
> testing time wouldn't be a significant portion of the interface
> cost)
>
> Regards,
>
> Steve
>
>
> ----------------------------------------------------------------------
> --
>
> *From:* OJHA,JUGNU [mailto:jugnu.ojha@xxxxxxxxxxxxx]
> *Sent:* Tuesday, August 29, 2006 11:48 AM
> *To:* STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> *Subject:* Re: [HSSG] BER Objective
>
> Roger,
>
> I understand that test time is the issue. The point I'm
> getting at (and which I've always wondered about) is, if the
> errors are so few and far between that it takes so long to
> find them, how much impact can they really be having on the
> system/network performance? I.e., are we being too demanding
> with the BER requirements.
>
> Jugnu
>
>
> ----------------------------------------------------------------------
> --
>
> *From:* Roger Merel [mailto:roger@xxxxxxxxxxx]
> *Sent:* Tuesday, August 29, 2006 10:44 AM
> *To:* STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> *Subject:* Re: [HSSG] BER Objective
>
> It's not hard to measure, just time consuming. If one wants to
> keep optics affordable, one need manufacturing test to be
> <minutes, not >10 minutes.
>
> Although my position is that 1E-15 BER is not required; but
> only 1E-13 at most.
>
>
> ----------------------------------------------------------------------
> --
>
> *From:* OJHA,JUGNU [mailto:jugnu.ojha@xxxxxxxxxxxxx]
> *Sent:* Tuesday, August 29, 2006 10:37 AM
> *To:* STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> *Subject:* Re: [HSSG] BER Objective
>
> All of this raises the following question: If this is so hard
> to measure, how much impact can it really have in the real
> world? Why not back the BER requirement off to 10e-10?
>
> Regards,
>
> Jugnu
>
>
> ----------------------------------------------------------------------
> --
>
> *From:* Petar Pepeljugoski [mailto:petarp@xxxxxxxxxx]
> *Sent:* Monday, August 28, 2006 8:03 PM
> *To:* STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
> *Subject:* Re: [HSSG] BER Objective
>
>
> I agree with Howard. It is impractical and expensive to test
> for very low BERs - the specs should be such that the power
> budget is capable of achieving BER =1e-15, yet the testing can
> be some kind of accelerated BER at lower value that is derived
> from the curve interpolation.
>
> However, the as with any extrapolation of testing results one
> has to be careful, so in this case it will be manufacturers'
> responsibility to guarantee the BER=1e-15.
>
> Regards,
>
> Petar Pepeljugoski
> IBM Research
> P.O.Box 218 (mail)
> 1101 Kitchawan Road, Rte. 134 (shipping)
> Yorktown Heights, NY 10598
>
> e-mail: petarp@xxxxxxxxxx
> phone: (914)-945-3761
> fax: (914)-945-4134
>
> *Howard Frazier <hfrazier@xxxxxxxxxxxx>*
>
> 08/28/2006 05:39 PM
>
> Please respond to
> Howard Frazier <hfrazier@xxxxxxxxxxxx>
>
>
>
> To
>
>
>
> STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx
>
> cc
>
>
>
> Subject
>
>
>
> Re: [HSSG] BER Objective
>
>
>
>
>
>
>
> For the 100 Mbps EFM fiber optic links (100BASE-LX10 and
> 100BASE-BX10)
> we specified a BER requirement of 1E-12, consistent with the
> BER requirement
> for gigabit links. We recognized that this would be
> impractical to test in a
> production environment, so we defined a means to extrapolate a
> BER of 1E-12
> by testing to a BER of 1E-10 with an additional 1 dB of
> attenuation. See
> 58.3.2 and 58.4.2.
>
> Howard Frazier
> Broadcom Corporation
>
>
> ----------------------------------------------------------------------
> --
>
> *From:* Roger Merel [mailto:roger@xxxxxxxxxxx] *
> Sent:* Monday, August 28, 2006 1:54 PM*
> To:* STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx*
> Subject:* Re: [HSSG] BER Objective
>
> David,
>
> Prior to 10G, the BER standard (for optical communications)
> was set at 1E-10 (155M-2.5G). At 10G, the BER standard was
> revised to 1E-12. For unamplified links, the difference
> between 1E-12 and 1E-15 is only a difference of 1dB in power
> delivered to the PD. However, the larger issue is one of
> margin and testability (as the duration required to reliably
> verify 1E-15 for 10G is impractical as a factory test on every
> unit) especially since we'd want to spec worst case product
> distribution at worst case path loss (cable+connector loss)
> and at EOL with margin. Thus in reality, all products ship at
> BOL from the factory with a BER of 1E-15 and in fact nearly
> all will continue to deliver 1E-15 for their entire life under
> their actual operating conditions and with their actual cable
> losses.
>
> Thus, if by "design target", you mean a worst case-worst case
> with margin to be assured at EOL on every factory unit, then
> this is overkill. I might be willing to entertain a 1E-13 BER
> as this would imply that same number of errors per second (on
> an absolute basis; irrespective of the number of bits being
> passed; this takes the same time in the factory as verifying
> 1E-12 at 10G although this is in fact a real cost burden which
> adversely product economics); however, this would not
> substantially change the reality of the link budget. It would
> make for a sensible policy for the continued future of bit
> error rate specs (should their be future "Still-Higher-Speed"
> SG's).
>
> -Roger
>
>
>
> ----------------------------------------------------------------------
> --
>
>
> *From:* Martin, David (CAR:Q840) *
> Sent:* Friday, August 25, 2006 12:22 PM*
> To:* STDS-802-3-HSSG@xxxxxxxxxxxxxxxxx*
> Subject:* BER Objective
>
> During the discussion on Reach Objectives there didn't appear
> to be any mention of corresponding BER.
>
> Recall the comments from the floor during the July meeting
> CFI, regarding how 10GigE has been used more as infrastructure
> rather than as typical end user NICs. And that the application
> expectation for 100GigE would be similar.
>
> Based on that view, I'd suggest a BER design target of (at
> least) 1E-15. That has been the defacto expectation from most
> carriers since the introduction of OC-192 systems.
>
> The need for strong FEC (e.g., G.709 RS), lighter FEC (e.g.,
> BCH-3), or none at all would then depend on various factors,
> like the optical technology chosen for each of the target link
> lengths.
>
> ...Dave
>
> David W. Martin
> Nortel Networks_
>_dwmartin@xxxxxxxxxx <mailto:dwmartin@xxxxxxxxxx>
> +1 613 765 2901 (esn 395)
> ~~~~~~~~~~~~~~~~~~~~
>
--
Michael J. Bennett
Sr. Network Engineer
LBLnet Services Group
Lawrence Berkeley Laboratory
Tel. 510.486.7913