Manual:System/Health: Difference between revisions
No edit summary |
No edit summary |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
{{Warning|This manual is moved to https://help.mikrotik.com/docs/display/ROS/Health}} | |||
==Summary== | ==Summary== | ||
Hardware that supports monitoring will display different information about hardware status, like temperature, voltage, current, fan-speed, etc. | Hardware that supports monitoring will display different information about hardware status, like temperature, voltage, current, fan-speed, etc. | ||
| Line 36: | Line 37: | ||
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. | 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 [https://mikrotik.com/products 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== | ==Fan control and behaviour== | ||
<pre>/system health set</pre> | <pre>/system health set</pre> | ||
Using this menu users will be able to control fan behaviour on TILE architecture [https://mikrotik.com/download devices]. | Using this menu users will be able to control fan behaviour on TILE architecture [https://mikrotik.com/download devices]. | ||
Currently, for other RouterBOARD devices, there is '''no''' option to manually control FAN behaviour. | Currently, for other RouterBOARD devices, there is '''no''' option to manually control FAN behaviour. | ||
{{ Note | Improved FAN stability starting from version 6.45.5.}} | {{ 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 | 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=== | ===PoE-out consumption=== | ||
If device has PoE-out, then fan RPM will change as described below: | If a device has PoE-out, then the fan RPM will change as described below: | ||
{| class="wikitable" | {| class="wikitable" | ||
| Line 68: | Line 65: | ||
|} | |} | ||
For devices with '''PWM''' fans speed will | 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=== | ===CPU and SFP temperature=== | ||
If CPU | 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. | |||
Currently exception | |||
{{ Note | All readings are approximate and may not be 100% precise | {{ Note | All readings are approximate and may not be 100% precise. Their purpose is to ~inform users about possible/upcoming failures. }} | ||
[[Category: Manual|Health]] | [[Category: Manual|Health]] | ||
Latest revision as of 09:36, 22 December 2021
Warning: This manual is moved to https://help.mikrotik.com/docs/display/ROS/Health
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
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
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.
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.
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.
Note: All readings are approximate and may not be 100% precise. Their purpose is to ~inform users about possible/upcoming failures.