Boards and profiles

General board parameters

The board configuration is divided in two main parts: the first one just defines the default profile, and the next ones 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 map 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 very well) or override it's 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 by using the max_reboots field (defaults to 5).

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

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 a board. 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 controle, it is also possible to create user-defined profiles with the profilenew API command. It is also possible to set the profile of a board 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 = 3
amplified_factor = 0.1

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 for each chip. The amplified_factor 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.

You can change those values via the healthctrlset API command.