Boards and profiles
The board configuration is divided in two main parts: the first one just defines the defaultt profile, and the next onescan 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.
Per 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.
[hashboard] profile = "default" [hashboard.boards.0] enabled = true profile = "efficiency"
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 parameter to be used by a board. Different miner models have different characteristics, so the profiles are defined in a "per-model" basis and have an internal format suitable for that model.
For example, on an AntMiner S9, the default profile is located at
/profiles/s9/default.toml, and have the following content:
# Metadata information [metadata] name = "default" author = "Luxor Technologies <[email protected]>" version = "0.1.0" target_model = "s9" locked = true # S9 can have voltage and frequency defined "per-board" # these are the defaults this profile sets [defaults] frequency = 650 voltage = 8.9
As you can see, the "default" profiles change the board run on a voltage of 8.9V and to use a 650Hz frequency on every chip. Different profiles will, of course, have different values. To create your own custom profile, create a file with a similar content, in the same path, but using your custom parameters.
Pay attention to the name and the model
When loading profiles during initialization, luxminer will only load them if the model matches the miner model. The profile name must also match the file name.
Additionally, single-voltage models do not support boards with different profiles; if you set the profile on a given board, it will set all of them.
Since profiles are loaded at initialization, you will need to restart luxminer for your new profile to be picked up. Another, more convenient option, is to use the UI to upload a profile instead; this will trigger the loading of the new profile immediately.
You might now be wondering what is the point of having a separate profile system, if we might as well just put those specific parameters directly in the main configuration. What is the catch?
The "catch" here is that profiles are able to store not only board-specific parameters (much like the main TOML file), but also per-chip frequency configuration. This works together with the frequencyset and voltageset commands to save it to the profile, so next time your miner reboots, the exact values of the last run are automatically restored.
LUXminer ships with a set of built-in profiles, all of them
locked by default, so you can easily "revert" to them in case os misconfiguration. They are called
default (should work for most machines),
efficiency (very good energy vs hashrate ratio) and
performance (forget power costs, give me increased performance).
If you accidentally delete any of the built-in profiles, they will be recreated next time luxminer starts.
Besides all the board parameters we've seen so far, it is also possible to configure the automatic healthcheck behavior. 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.
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/defective hardware.