Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Bill, I am not going to defend BER as the ultimate solution. This topic comes up in almost every SG that I have ever participated in and people complain about BER. Proposals are made, lots of cycles are burnt on how to do that right and then … no changes are made because there is never consensus on how to do that right in an interoperable and reproducible manner. If we do something new, we will be setting precedence and there will be plenty of scrutiny. Also, there is always resistance from the industry that knows how to test BER, but would have to change procedures to adopt a new testing procedures. With that said, I’d really love us not to spend a lot of time on this topic and get lost in the forest. We have PHY to develop and not specify methods for testing errors in a transmission channel Marek From: Bill Wall (wallb) [mailto:wallb@xxxxxxxxx] Sorry for jumping in here, but this can be a good example of why BER is not relevant. Consider a frame of 2000 bytes (approximately the length of the DVB C2 LDPC code). According to this requirement a frame error rate of 2000 x 8x10^-8 = 1.6x10^-4 would meet the requirement. Now depending on how the FEC fails, many bits in the failed frame could be wrong. If it was totally wrong and bits were random 50% might be wrong, which would give a BER of 8x10-5 that would still give an acceptable frame error rate. -Bill From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx] Dear Tom, Just one clarification – the number you quote as requirement, is not a requirement. It is an informative note, which has no weight when it comes to the interpretation of the standard. The requirement speaks of “8x10^-8 error rate per octet of MAC frame length” (this is where the shall statement is placed) and this is what we have to be able to demonstrate. Everything else does not matter (or almost does not matter). If you could kindly provide calculations showing what BER we’d have to be working at to guarantee that kind of error rate at MAC service interface, I believe it would be a very valuable contribution for this group. And please, do provide all calculations (Excel would be nice) so that people can go and run their own calculations as well. We are mostly engineers in here and like number crunching J Regards Marek From: Thomas Kolze [mailto:tkolze@xxxxxxxxxxxx] Duane, Marek, Thank you very much for your feedback, comments, and substantive responses in your emails (in this string). The bottom line of the architecture document passages you have provided is that while secondary targets are created, such as “8x10^-8 error rate per octet,” the PRIMARY requirement in the architecture document is in fact Packet Error Rate (referred to as “frame error rate” in the text you provided). The Packet Error Rate requirement for a 1518 byte packet is 1.21x10^-4 according to the provided and highlighted text from the architecture document. I am thrilled at your quick and expert feedback; your feedback shows that the objectives I suggest for EPoC error rate requirements --- both the TYPE of error rate requirement AND the values of the error rate requirement --- ARE NOT IN VIOLATION of, and in fact are aligned WITH, the over-arching architecture document of IEEE 802.3. Thank you sincerely. I greatly appreciate your raising my awareness of the architecture document and its contents in this regard. I would have loved to have had that information PRIOR to making the presentation of my submission for error rate recommendations for EPoC. Later, tjk [Tom Kolze Broadcom] From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx] Thank you Duane, One of the 5 Critters clearly states that we have to maintain compliance with 802 architecture. Here is a quote: IEEE 802 defines a family of standards. All standards should be in conformance with the IEEE 802.1 Architecture, Management, and Interworking documents as follows: IEEE 802. Overview and Architecture, IEEE 802.1D, IEEE 802.1Q, and parts of IEEE 802.1F. If any variances in conformance emerge, they shall be thoroughly disclosed and reviewed with IEEE 802.1. Each standard in the IEEE 802 family of standards shall include a definition of managed objects that are compatible with systems management standards. Compatibility with IEEE Std 802.3 Conformance with the IEEE Std 802.3 MAC Managed object definitions compatible with SNMP The part of interest is highlighted in red to make sure it is not missed. As you can see, we may have some leeway opening exception to compliance, but is a rough way if we chose to go. It would be a time consuming effort, with lots of questions asked at each turn of the way. In short, I suggest we maintain the compatibility with the necessary documents and look at how it could be achieved at the physical layer. Marek From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx] All, In reviewing the EFM WEB site it appears that the task force was operating under a different set of objectives between approval of the TF in July 2001 and March 2002. The initial objectives approved by the WG did not appear to include any error rate requirement. The subsequent objectives including the error rate for the optical interfaces were not approved by the WG until the March. My conclusion is that there is precedence for objectives without error rates. That said I must agree with Marek in his observation that we must comply with the architecture doc. Best Regards, Duane FutureWei Technologies Inc. Director, Access R&D 919 418 4741 Raleigh, NC From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx] Here is the excerpt from 802-2004 architecture document that puts bounds on how high in BER/PER we can go Regards Marek <="" p=""> <="" p=""> |