RE: Ideally BER should be a customer controlled option
- To: bill.st.arnaud@xxxxxxxxxx, Rich Seifert <seifert@xxxxxxxxxx>, Jaime Kardontchik <kardontchik.jaime@xxxxxxxxxxx>, "Chang, Edward S" <Edward.Chang@xxxxxxxxxx>, stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
- Subject: RE: Ideally BER should be a customer controlled option
- From: "Chang, Edward S" <Edward.Chang@xxxxxxxxxx>
- Date: Tue, 1 Jun 1999 16:41:47 -0400
- Sender: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
It seems you picked one unpopular suggestion, so far, no one seems to agree
with you yet.
Sorry, my friend, I am also not quite ready for a flexible BER.
In addition to the comments from others which I agree, if we let BER be
flexible, we will have incompatibility equipment all over, and we may need
something similar to auto-negotiation to find the BER (reliability) of other
terminals before transferring data. I do not think we need that extra
trouble. So far the BER works fine for us to set the minimum reliability
for data transfer, and COST-EFFECTIVE.
From: Bill St. Arnaud [mailto:bill.st.arnaud@xxxxxxxxxx]
Sent: Sunday, May 30, 1999 8:30 PM
To: Rich Seifert; Jaime Kardontchik; Chang, Edward S;
Subject: Ideally BER should be a customer controlled option
Realizing that there are some practical limitations, as much as possible,
BER should be a customer controlled option.
If I am running only IP with high number of a TCP transmissions I may
deliberately want a high BER to act as layer 1 WRED. Also I may be able to
push my repeater distance using low cost laser and a willing to suffer a
If I am running some other protocol I may require a lower BER.
I always believe in giving the customer as much choice as possible. I don't
we should play god and decide before hand what is the best BER for our
Bill St Arnaud
Director Network Projects
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Rich
> Sent: Friday, May 28, 1999 2:53 PM
> To: Jaime Kardontchik; Chang, Edward S;
> Subject: Re: 1000BASE-T PCS question
> At 9:11 AM -0700 5/27/99, Jaime Kardontchik wrote:
> >My impression is that it would have been much more simpler if
> the group had
> >been called "10-Gigabit-Ethernet" instead of "Higher-Speed
> Group". At some
> >time in the future the group will have to decide what kind of
> standard to work
> Well, it was not clear at all (and still is not clear) that a
> single-speed of
> 10 Gb/s is the goal of all of the study group members, or indeed reflects
> the needs of the user community. It is one of the purposes of the Study
> Group to determine what speed(s) should be supported in a standard.
> >Ethernet standards deliver a BER of 10^(-10).
> This is simply not true. The BER spec for 10BASE5 is 10^-9. For
> 10BASE2 and
> 10BASE-T, it is 10^-8. For 100BASE-X and 1000BASE-X, it is 10^-12.
> The BER goals for any higher-speed standard should be determined
> by the SG.
> Further, BER is really a parameter more relevant to serial transmission
> systems that do not use any block-coding; in such systems it is
> straightforward to map between the BER and the Frame Loss Rate (a more
> significant parameter in a connectionless, best-effort frame delivery
> system). We had long discussions both in Fast Ethernet and
> 1000BASE-T about
> how many frame errors are generated by a single bit error, the
> between symbol errors and bit errors, etc. In the end, the only observable
> characteristic at the MAC service interface is the Frame Loss Rate. I
> propose that any future standards work use this parameter to characterize
> the error performance of the system, rather than BER.
> Rich Seifert Networks and Communications Consulting
> seifert@xxxxxxxxxx 21885 Bear Creek Way
> (408) 395-5700 Los Gatos, CA 95033
> (408) 395-1966 FAX
> "... specialists in Local Area Networks and Data Communications systems"