Today I am releasing the first development version of the upcoming rig-monitor 3.0 release.

Initially I was planning to have a minor version release, which would add the profitability logic and dashboards, but soon after starting the development I realized the complexity of adjusting the profitability queries to each pool & miner combination so I decided to address that as part of a major release. Thus, the focus on release 3.0 is not only to add the profitability functionality, but also to completely remove the need for users to reconfigure the template dashboards to their setup. In order to improve the usability I had to change quite a few things:

  1. Miner and pool specific dashboard templates are deprecated and replaced by the “Mining Overview Dashboard”. This dashboard features dozens of operational and business charts and gauges including key rig and pool metrics, market prices and data, future and past profitability, etc….
  2. Instead of manually having to modify each chart’s query for their own needs, the dashboard includes drop-down list (populate with influx data at load time) that allows the user to select which pool data to display. Based on the pool selection the relevant miners, crypto and currency are automatically selected.
  3. To enable the previous bullet is was necessary to ensure metric  consistency across miners and pools. So the first step was to define the list of common field keys across those. Miner and pool specific fields are, in many cases still stored in influxDB and available for those willing to create custom charts (soon I will publish the influx measurements schema for hose of you wishing to create custom chats with miner, pool specific metrics).
  4. Specifically to Claymore, whereas previously both ETH and dcoin data were stored in a single influxDB record from version 3.0 they are stored as two different, independent records, having a different (pool) label.
  5. Harmonizing the units access  the common metrics e.g. previously Claymore hashrate was stored in MH/s whereas sgminer, xmr-stak stored them in H/s. This is critical in order to accurately display and calculate some metrics e.g. future profitability (you can read more about it later in this post)
  6. Introduction of a new pool line configuration parameter: “hashrate correction factor”.  Some pools e.g. nanopool, MPOS pools report hashrates in KH/s or MH/s (also depending on the crypto) and because they provide no units it’s impossible for rig-monitor to know what the order of magnitude is. So the user will have to configure that param manually as part of the rig-monitor (config file) configuration .

And that brings us to the profitability charts.

Basically there are 2 types of charts (and respective backend logic):

  • Historical profitability
  • Future profitability

Historical profitability

Historical profitability calculates the previous N day mining operation profitability for a given pool and rigs mining on that pool.

How does rig-monitor know which pool a given rig is mining on? That’s the label field in the rigList array of the config file e.g.


But let’s take this step-by-step.

Daily power costs (in quote currency as defined in config file) is calculated as the sum of every rig’s average power usage for all rigs mining on the selected pool.

Daily revenue (in crypto) is calculated based on the sum of daily payments made from the selected pool, multiplied by the respective cryptos’s daily average price point.

And finally, daily profitability, is simply the pool’s daily revenue minus the (power) costs of mining rigs on that pool.

Past profitability is stored in influx’s past_profit measurement. Here’s the table schema:

labeltagpool label as defined in config file
power_costs_24hfielddaily sum of power costs for all rigs mining in pool (label)
revenue_24hfielddaily revenue (sum of pool payments) in quote currency
price_btc_24hfielddaily average crypto exchange rate in BTC
price_qc_24hfielddaily average crypto exchange rate in quote currency (defined in config file)
profitability_24hfielddaily profitability

Note! You can still use the profitability dashboards, even if you don’t have Wemo or TP-Link smart plugs, by using the “noplug” option in the rig configuration. That option will log the “power usage” for the rig as a constant value as defined in the max_power field of the rig configuration. (See notes in config.toml for more information).

Future profitability

Future profitability calculation is different from historical profitability. Whereas the (power) cost estimations are still based on (power) usage data, the revenue estimation (per rig) is based on rigs’ hashrate and a bunch of blockchain parameters.

Estimated (power) costs are based on the average rig power usage during the previous 24 hours.

Estimated revenue, as mentioned above, depends on several parameters, including block reward, block time, network hashrate, mining hashrate and crypto price point:

revenue = mining_hashrate / (network_difficulty / block_time) * (60 / block_time) * block_reward * (60 * 24) * price_quote_currency

And so 24h profitability forecast can be calculated by subtracting the costs from the revenue outlook.

All this works well, but there are a couple important points to make.

  1. the blockchain params and price info is fetched from and If the mined crypto data is not published on those sites then the profitability calculations  will fail.
  2. Previously miner hashrate was store in whatever units the miner’s API provided e.g. Claymore in MH/S, xmd-stak in H/s. These discrepancies would have required some charts to be manually adjust in order to provide accurate data e.g. future profitability, which depends on the rig’s hashrate (see above). Therefore, in this same release, and from now on, miner hashrate will be always stored in H/s.
  3. After a few days of testing the future profitability calculation seems to be a bit off so better estimates may come from using the pool reported hashrate. I will not change it at this point until I get feedback from some users willing to test this version.

Future profitability is stored in influx’s future_profit measurement. Here’s the table schema:

rig_idtagrig_id as defined in config file
power_costs_24hfieldpower costs estimate based on rig's average power usage during the previous 24h
revenue_24hfieldrevenue estimate based on rig's average hashrate during the previous 24h
block_timefieldaverage block creation time during the previous 24h
block_rewardfieldaverage block reward during the previous 24h
difficultyfieldaverage network difficulty during the previous 24h
price_fieldaverage crypto exchange rate in quote currency during the previous 24h e.g. price_usd

Leave a Reply

Your email address will not be published. Required fields are marked *