Boards and profiles
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
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
With LuxOS, you not only have the ability to see which connector your hashboard is using but also connect your hashboard to the extra hashboard connector and keep hashing without having to swap your control board because of a single bad connector.
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.
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.