Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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=""> |