The time elapsed after the LSR_WILL_DIE alarm is reported and before the laser of the board is damaged

7

Currently, no statistics are available. The LSR _ WILL _ DIE alarm indicates that the components of the laser are aging, and the output optical power starts to deteriorate. However, the aging speed of the laser varies depending on actual conditions. Therefore, it is recommended that you replace the optical module in the optical port or replace the board after the board reports the LSR_WILL_DIE alarm.

Other related questions:
Impact of the LSR_WILL_DIE alarm reporting on the board laser
Currently, there is no statistics data. The LSR_WILL_DIE alarm indicates that the laser starts aging and its output power begins to degrade gradually. However, the laser aging speed is affected by many factors. To prevent board failures, you are advised to replace the optical module on the related optical port or directly replace the board as soon as possible after a LSR_WILL_DIE alarm is reported.

Clearing of the LSR_WILL_DIE alarm after the fan speed is adjusted to high speed
The LSR_WILL_DIE alarm is a module alarm and is affected by the temperature. It is reported when the module is in the high temperature environment and ages quickly. You are advised to replace the module or board even if the LSR _ WILL _ DIE alarm is cleared by increasing the fan speed.

Whether the FIU board reports the MUT_LOS alarm
Yes, it does.

Cause for transient alarm reporting on TOM boards
On the OSP platform, alarm reporting has anti-jitter mechanisms. The anti-jitter time for alarm reporting is 2.5s and that for alarm clearing is 10s. If a board alarm task can be reported to the platform at least two consecutive times within 2.5s, alarms may not be transiently reported. If the alarm task reporting interval of a board is greater than 2.5s, transient alarm reporting probably occurs. The alarm task reporting interval of most boards is 1s and alarm status can be reported twice in 2.5s. If an alarm is found during the first detection but cleared during the second detection, the alarm will not be reported. In this manner, transient alarm reporting can be effectively avoided. To reduce the CPU usage, the alarm task reporting interval of TN11TOM boards is 2s but that of TN52TOM boards. As a result, the alarm status may be reported only once in the 2.5s anti-jitter period. Consequently, the alarm anti-jitter mechanism does not take effect and an alarm is reported and lasts 1s. If a higher-priority task preempts the alarm task, the alarm task reporting interval may be longer and the alarm may last for more than 1s. Therefore, TOM boards are prone to report alarms in case of transient service interruption. When bit errors are present on a line, a TOM board may falsely detect that the BDI byte is reset to 1 and therefore transiently reports alarms such as ODU1_PM_BDI. As a result, alarms such as ODU1_PM_DEG may be transiently reported upon SNCP protection switching.

Possible cause of the BUS_ERR alarm that is reported on an NS2 board after OptiX OSN 6800 is upgraded
The possible cause of the BUS_ERR alarm is that the board mode is incorrect. You are advised to modify the value of the line mode parameter.

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