Relationship between the OPUk_PLM alarm and ODUk_PM_UAS performance


According to the G.8021 protocol, near-end alarms are associated with bit error performance. Near-end alarms include OCh LOS, OTUk LOF, OTUk AIS, OTUk TIM, ODUk OCI, ODUk AIS, ODUk LCK, ODUk TIM, and OPUk PLM.
The generation conditions of the severely errored second (SES) are as follows: When there are no less than 30% bit errors or at least one defective second, a near-end alarm will cause a near-end SES. The SES is converted to a UAS performance after lasting 10s.
Therefore, an OPUk PLM alarm is a defect that can trigger an SES. That is, if the PM itself has no bit errors but the PT values to-be-received are inconsistent with those that are actually received, an ODUk_PM_UAS performance occurs.
It cannot be simply inferred that the ODUk UAS causes the OPUK_PLM alarm just because the ODUk layer is higher than the OPUk layer.

Other related questions:
Relationships between redundancy ratio, strip size, and read/write performance of OceanStor 9000
Relationships between redundancy ratio, strip size, and read/write performance of OceanStor 9000: The redundancy ratio and strip size of OceanStor 9000 directly impact on the storage space utilization. The strip size determines the data slice size. The data slice size is set based on the average size of files in actual services to prevent improper data slices due to a too large strip size, avoiding space waste. Particularly for small files, small strips of 16 KB are needed. The redundancy ratio determines the number of verification data copies and directly impacts on the storage space utilization. For the N+M redundancy ratio in the Erasure Code algorithm, M can be 1, 2, 3, or 4. A larger value of M indicates poorer algorithm performance and more complex computing. N can be 3 to 16. A larger value of N indicates higher algorithm performance and more disks concurrently read/written.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top