Manual:System/Health

From MikroTik Wiki
< Manual:System
Revision as of 11:55, 20 April 2020 by Elans (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Summary

Hardware that supports monitoring will display different information about hardware status, like temperature, voltage, current, fan-speed, etc.

Example on CCR1072-1G-8S+ device:

          cpu-overtemp-check: yes
      cpu-overtemp-threshold: 100C
  cpu-overtemp-startup-delay: 1m
             cpu-temperature: 46C
           power-consumption: 62.9W
          board-temperature1: 31C
          board-temperature2: 34C
                psu1-voltage: 12.1V
                psu2-voltage: 0V
                psu1-current: 5.2A
                psu2-current: 0A
                  fan1-speed: 6375RPM
                  fan2-speed: 6436RPM
                  fan3-speed: 6375RPM
                  fan4-speed: 6467RPM

Icon-warn.png

Warning: For feature availability on RouterBOARD products check mikrotik.com



Voltage

Routers that support voltage monitoring will display supplied voltage value. In CLI/Winbox it will display volts. In scripts/API/SNMP this will be dV or value showed in CLI/Winbox multiplied by 10

Icon-note.png

Note: Routers that have PEXT and PoE power input are calibrated using PEXT, as a result, value showed over PoE can be lower than input voltage due to additional ethernet protection chains.


Icon-note.png

Note: If old revision CRS112, CRS210 and CRS109 devices are powered with PoE - Health will show correct voltage only up to 26.7V. If higher voltage will be used - Health will show constant 16V.


Temperature

Routers that support temperature monitoring will display temperature reading. In CLI/Winbox it will display degrees Celsius. Using scripts/API/SNMP this value will be shown in CLI/Winbox multiplied by 10. There are various temperature sensors depending on the device. These sensors may refer to: cpu-temperature, pcb-temperature, sfp-temperature. Device tested ambient temperature range you can find in specification description at mikrotik.com. Tested ambient temperature range is temperature in which device can be physically located. It is not the same as temperature which reports system health monitor!

Fan control and behaviour

/system health set

Using this menu users will be able to control fan behaviour on TILE architecture devices. Currently, for other RouterBOARD devices, there is no option to manually control FAN behaviour.

Icon-note.png

Note: Improved FAN stability starting from version 6.45.5.


There are three parameters that may affect fan behaviour: PoE-out consumption, SFP temperature and CPU temperature. As soon as one of the parameters exceeds the optimal value the, fans are started.

PoE-out consumption

If a device has PoE-out, then the fan RPM will change as described below:

PoE-out load RPM % of max FAN speed (DC fans)
0%..24% FAN speed 0%
25%..46% FAN speed 25%
47%..70% FAN speed 50%
71%..92% FAN speed 75%
93%.. FAN speed 100%

For devices with PWM fans, the speed will linearly increase or decrease from 9..88% (note: below 100W the fan RPM=0)

CPU and SFP temperature

If CPU or SFP temperatures exceed 58C, the fans will start to spin. The higher the temperature, the faster the fans will spin. For devices with PWM fans, as the CPU or SFP temperatures exceed 58C, the fans will linearly increase their RPM to try to keep the temperature at 58C if possible. For devices with DC fans, as the CPU or SFP temperatures exceed 58C, the fans will start spinning but at a higher minimum RPM by default. This may result in cooling the device to the point where the fans turn-off completely. After which the temperature may slowly increase to 58C and the fans will turn on again. Currently, there is one exception. The S+RJ10 modules have a temperature threshold of 65C before they trigger the fans. Since it's a higher temperature threshold, the fans will start spinning at a higher initial speed to cool the device.

Icon-note.png

Note: All readings are approximate and may not be 100% precise. Their purpose is to ~inform users about possible/upcoming failures.