Boards and profiles

General board parameters

The board configuration is divided into two main parts: the first one defines global params that apply to all boards like profile, max_reboot, overtemp_auto_recovery and no_pic_protection_mode, and the next part can be used to override new values for specific boards, using the format hashboard.boards.X, where X is the board number. The board number starts from 0 for the first connector (J1), so you can easily map between connectors and board IDs.

For each board, you can override its enabled status (for example, disabling a board that isn't working well) or override its profile, perhaps to use a profile that doesn't drive it as hard as the others. It is also possible to set the maximum number of (system) reboots before giving up on that board using the max_reboots field (defaults to 5).

[hashboard]
profile = "default"
 
[hashboard.boards.0]
enabled = true
max_reboot = 10

The overtemp_auto_recovery options defines the way the system will react when detecting system temperature reaches the configurable dangerous temp. When set to true or empty, the system will try to restart the board to reduce temperature. When set to false, the system will shutdown all boards and also PSU if needed. The no_pic_protection_mode options defines the way the system will react when detecting a failing board in miners with no physical protection. When set to shutdown_all_boards or empty, the system will shut down all boards and turn off PSU in order to protect miner. When set to shutdown_failing_board, the system will only shut down the failing board. Please note that overtemp_auto_recovery and no_pic_protection_mode are a global parameters and can't be overridden per board.

Profiles

At this point, you might be wondering what exactly is that profile key on the board configuration. A profile is nothing more that a file that stores the set of parameters to be used by the hashboards. Profiles are created dynamically by reading the "optimal" factory specs from you board and storing it on the default profile. A number of under and over clocking profiles are also created, giving you a safe range to try new configurations.

For those who wants more control, it is also possible to create user-defined profiles with the profilenew API command. It is also possible to set the profile for the machine using the profileset command.

Healthcheck configuration

LUXminer has an automatic healthchecker that is always running and provides information for many other system services to help them make decisions based on how good (or bad) the boards are performing. Its behavior can lso be changed directly in the toml file, and the default configuration looks like this:

[hashboard.health]
num_readings = 120
bad_chip_health_threshold = 0.2

The default configuration have reasonable values to give it a good performance when checking the chips, and it is unlikely that most users will want or need to change those values. Increasing num_readings uses more data for the checking, and the tradeoff is the increased time to get the health results. The bad_chip_health_threshold can be increased to make the checking requirements more strict, but also increase the chance of marking chips as "bad" on aging or defective hardware.

The number of readings on this configuration assumes a 100MHz operational frequency and scales down as the frequency goes up. This means that if you double the frequency, the system will automatically compute the results with only half he number of readings.

You can change those values via the healthctrlset API command.