Boards and profiles
General board parameters
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 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.
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"
Hashboard connectors
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.
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 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.
The "why" of profiles
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.
Built-in profiles
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.
Healthcheck configuration
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.