Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Ideally BER should be a customer controlled option




Bill:

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. 

Ed Chang   

 

-----Original Message-----
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;
stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Subject: Ideally BER should be a customer controlled option



All:

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
higher BER.

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
customers.

Bill



-------------------------------------------
Bill St Arnaud
Director Network Projects
CANARIE
bill.st.arnaud@xxxxxxxxxx
http://tweetie.canarie.ca/~bstarn

 

 



> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Rich
> Seifert
> Sent: Friday, May 28, 1999 2:53 PM
> To: Jaime Kardontchik; Chang, Edward S;
> stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> 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
> >on.
> >
>
> 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
> relationship
> 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"
>
>