-
Notifications
You must be signed in to change notification settings - Fork 208
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
5 changed files
with
333 additions
and
2 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,111 @@ | ||
| Team Red Miner Dual Coin ETH Mining | ||
| =================================== | ||
|
|
||
| TL;DR | ||
| ----- | ||
| To mine ETH+TON on Navi gpus (which is the only supported dual algo at the moment), | ||
| take a working TRM ethash command line and add a TON section in the | ||
| middle or at the end: | ||
|
|
||
| --ton -o stratum+tcp://ton.hashrate.to:4002 -u <ton wallet>.<worker> -p x --ton_end | ||
|
|
||
| TRM's dual mining setup let's the user split the capacity between | ||
| ethash and the second algo using the standard --eth_config | ||
| argument. The higher intensity, the more capacity for ethash and less | ||
| for the dual algo. Therefore, you SHOULD remove any existing | ||
| --eth_config arguments in your ethash command line. They're not | ||
| applicable. Let the miner run the dual algo tuner once, then you can | ||
| add back a static config. The dual tuner will output a list of the | ||
| probed results. | ||
|
|
||
| If you run ETH+TON dual mining on unsupported gpus, a warning is | ||
| issued and they are downgraded to regular ethash mining only. This | ||
| makes it possible to run ETH+TON on mixed rigs where Navis will run | ||
| dual mining, other gpus plain ethash. | ||
|
|
||
| Last, see the TON dual mining section in USAGE.txt or the miner's | ||
| --help output for additional arguments. | ||
|
|
||
|
|
||
| Overview | ||
| -------- | ||
| From v0.9.2, TRM includes support for true dual mining together with | ||
| ethash. The first release is very much an experimental alpha version, | ||
| and support is limited to Navi and Big Navi gpus only. Subsequent | ||
| releases will add support for Vega and Polaris gpus and potentially | ||
| more dual mining algos - the single supported dual algo in the first | ||
| release is TON. | ||
|
|
||
| TRM's dual mining is configurable in the sense that the user decides | ||
| how the gpu capacity should be split between the two algos. This is | ||
| done with the normal --eth_config argument that decides how much gpu | ||
| capacity will be used by ethash. The remaining capacity will be used | ||
| by the dual algo. The eth config intensities used for single algo | ||
| ethash should _NOT_ be carried over to a dual mining setup. The dual | ||
| mining ethash kernel is designed differently and does not target the | ||
| absolute max possible ethash hashrate. It rather tries to provide a | ||
| good trade-off between running a very competitive ethash hashrate | ||
| close to the max possible while also providing room for the dual | ||
| algo to operate. | ||
|
|
||
|
|
||
| Dual mining ETH+TON | ||
| -------------------- | ||
| To dual mine ethash and TON, do as follows: | ||
|
|
||
| 1) Start with a working ethash configuration for TRM. | ||
|
|
||
| 2) If you have an --eth_config argument, remove the intensities. You | ||
| can keep the A/B-mode setting. | ||
|
|
||
| 3) Add a TON argument section that contains the pool(s) you want to | ||
| use for dual TON mining. This follows the same principle as TRM's | ||
| dual ZIL mining setup. This added argument will enable dual TON | ||
| mining on the Icemining pool: | ||
|
|
||
| --ton -o stratum+tcp://ton.hashrate.to:4002 -u <ton wallet>.<worker> -p x --ton_end | ||
|
|
||
| It's fully possible to insert the --ton ... --ton_end arguments | ||
| into e.g. a Hive flight sheet's custom miner arguments section to | ||
| enable dual mining, while still using Hive's builtin support for | ||
| configuring the ethash mining. | ||
|
|
||
|
|
||
| Clocks and Voltage Tuning | ||
| ------------------------- | ||
| Dual mining will inevitably pull significantly more power than single | ||
| algo ethash. The user is advised to tune a single gpu by itself first | ||
| to assess power draw. | ||
|
|
||
| Standard ethash clocks with a slight core voltage increase is a good | ||
| starting point for dual mining. After that, tuning is mostly a | ||
| function of achieving stability and how much power you want to | ||
| consume. Increasing core clk will increase the dual algo performance, | ||
| but at the cost of more power. | ||
|
|
||
|
|
||
| Dual Mining Ethash Modes and Intensity | ||
| -------------------------------------- | ||
| All ethash mining modes (A/B/C) are available in dual mining as well, | ||
| and behave like they do for single algo ethash mining. | ||
|
|
||
| For choosing the intensity, TRM includes a dual mining tuner that, | ||
| unless a static eth config intensity has been provided, scans through | ||
| a range of eth config intensities at startup and selects the optimal | ||
| one based on a scoring model. There are built-in weights for each pair | ||
| of algos that can be dual mined, but over time you might want to tweak | ||
| the optimization target function using the argument | ||
| --dual_tuner_weights=X:Y:Z. This argument is described in detail in | ||
| USAGE.txt and the miner's --help output. | ||
|
|
||
| As mentioned above, ethash config intensities from single algo ethash | ||
| mining should _NOT_ be used in a dual mining setting. We recommend | ||
| that you at least do one dual tuner run and inspect the output, or | ||
| always let the dual tuner run at startup. The process takes 3-4 | ||
| minutes to complete. | ||
|
|
||
| It should be noted that the dual tuner is somewhat crude and can | ||
| sometimes produce skewed results. This is mainly because we don't want | ||
| the process to take 10-15 minutes. The tuner outputs the results for | ||
| all scanned configurations after completing the scan, and the user can | ||
| pick a static config from there to add to the command line. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,86 @@ | ||
| Team Red Miner TON Mining | ||
| ========================= | ||
|
|
||
| TL;DR | ||
| ----- | ||
| TRM supports two TON pools: Icemining and Ton Coin Pool. Neither pool | ||
| requires wallet registration before starting to mine. Use the following | ||
| pool arguments to mine: | ||
|
|
||
| Icemining: -o stratum+tcp://ton.hashrate.to:4002 -u <ton wallet>.<worker> -p x | ||
|
|
||
| Ton Coin Pool: -o stratum+tcp://pplns.toncoinpool.io:443/stratum -u <ton wallet> -p <worker> | ||
|
|
||
| Last, see the TON section in USAGE.txt or the miner's --help output | ||
| for additional arguments. | ||
|
|
||
|
|
||
| Background | ||
| ----------- | ||
| TON is a special pow mining coin since submitted solutions aren't used | ||
| for network blocks and chain security like in standard pow | ||
| blockchains. Instead, TON has 10 smart contracts called "givers" that | ||
| simply reward you for hashing and submitting solutions directly to the | ||
| contracts. The remaining pool of available coins from the "givers" is | ||
| expected to last until mid-2022. | ||
|
|
||
| There is no single standard pool protocol for TON. All pools must be | ||
| handled as separate implementations. TRM currently only support the | ||
| following pools: | ||
|
|
||
| - Icemining (icemining.ca, beta stratum url ton.hashrate.to) | ||
| - TON Coin Pool (toncoinpool.io) | ||
|
|
||
| Even though it's a new pool in the TON ecosystem, we recommend | ||
| Icemining since it runs a well-designed pool protocol. Below you'll | ||
| find descriptions on how to use each supported pool. | ||
|
|
||
|
|
||
| Specifying Pool Protocol | ||
| ------------------------ | ||
| If you use the standard URLs for the supported pools, TRM will | ||
| automatically understand what pool protocol dialect to use. However, | ||
| if you tunnel the pool, connect by direct IP, or use some other | ||
| network mechanism that doesn't present the normal hostname to TRM you | ||
| must manually state which pool protocol should be used. This is done | ||
| using the --ton_pool_mode argument. These are the available options: | ||
|
|
||
| --ton_pool_mode=icemining | ||
|
|
||
| --ton_pool_mode=toncoinpool | ||
|
|
||
|
|
||
| Web Service Proxy | ||
| ----------------- | ||
| Many TON pools use web service protocols for its communication. TRM | ||
| does not include support for ws:// or wss:// in order to not violate | ||
| open source licenses, and we don't intend to spend the time | ||
| implementing support from scratch. Instead, we ship a proxy binary | ||
| that is compiled from a published open source project originally | ||
| written for mining Nimiq, which also uses wss:// for pool protocol | ||
| communication. The source code is available here: | ||
|
|
||
| https://github.com/Kerney666/trm_nimiq_proxy | ||
|
|
||
| The proxy is bundled in our release package and will be executed | ||
| automatically for you when necessary. | ||
|
|
||
|
|
||
| How to mine at Icemining | ||
| ------------------------ | ||
| Simply point TRM to the pool like for any other mining algorithm. TRM | ||
| will automatically split the worker name from the wallet if we find | ||
| that it ends with '.yourworkername'. It is not an official format for | ||
| specifying the worker. Replace ./teamredminer with teamredminer.exe | ||
| on Windows. | ||
|
|
||
| ./teamredminer --a ton o stratum+tcp://ton.hashrate.to:4002 -u <ton wallet>.<worker> -p x | ||
|
|
||
|
|
||
| How to mine at Ton Coin Pool | ||
| ---------------------------- | ||
| Use the following format to mine at Ton Coin Pool. Replace | ||
| ./teamredminer with teamredminer.exe on Windows. | ||
|
|
||
| ./teamredminer -a ton -o stratum+tcp://pplns.toncoinpool.io:443/stratum -u <ton wallet> -p <worker> | ||
|
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,71 @@ | ||
| Team Red Miner Dual Mining API Usage | ||
| ==================================== | ||
| This document describes how to use TRM's sgminer-compatible API when | ||
| dual mining is enabled. For resources on the sgminer api in general, | ||
| please see e.g. | ||
|
|
||
| https://github.com/genesismining/sgminer-gm/blob/master/doc/API.md | ||
|
|
||
|
|
||
| Overview | ||
| -------- | ||
| When TRM runs two algos, two separate contexts are used | ||
| internally. This is applicable both for dual eth+zil mining when the | ||
| --zil .. --zil_end arguments are used and for true dual mining like | ||
| eth+ton. | ||
|
|
||
| API requests are sometimes only returning global data applicable for | ||
| all algos, but many times a request provides data for a specific algo, | ||
| like hashrates, pool data, and more. When algo-specific data is | ||
| returned, data is always pulled from a single specific context. To | ||
| pull data for both algos, you must issue multiple requests or | ||
| subcommands. TRM provides two different approaches for doing so, both | ||
| described below. | ||
|
|
||
|
|
||
| Added fields | ||
| ------------ | ||
| To know if there's dual mining ongoing or not, a field called "Algo | ||
| Count" has been added to the CONFIG command. It will always return 1 | ||
| or 2 depending on the nr of concurrent algos being mined. | ||
|
|
||
|
|
||
| Solution 1: use --api2_listen | ||
| ----------------------------- | ||
| This solution acts like if two separate instances of TRM were running | ||
| on the same machine, mining two different algos on the same set of | ||
| gpus. The standard api is enabled by passing the --api_listen | ||
| argument, possibly with an interface IP address and/or a port. A | ||
| second such argument is now available, --api2_listen. This will open | ||
| another port for a second api endpoint. The miner will only open the | ||
| second api endpoint if dual mining is configured. | ||
|
|
||
| All requests to the first --api_listen endpoint will return data for | ||
| the primary algo being mined. Requests to the second endpoint defined | ||
| by --api2_listen will return data for the secondary algo. Both | ||
| endpoints are full API providers and will reply to all available | ||
| commands. | ||
|
|
||
| This solution is useful when using external tools that supports the | ||
| sgminer api (Awesome Miner is one example). You can enable both api | ||
| endpoints, then add each rig as two separate instances. | ||
|
|
||
|
|
||
| Solution 2: append 1 or 2 to command names | ||
| ------------------------------------------ | ||
| By modifying the command names available in the sgminer api | ||
| (e.g. "config", "devs", "summary") and appending a single digit, TRM | ||
| will return data for the algo in question. In other words, running the | ||
| command "pools2" will return data for all pools for the secondary algo | ||
| being mined, and e.g. "devs1" or just "devs" will return mining data | ||
| for all devices for the primary algo. | ||
|
|
||
| This solution is simple to use if you have your own api code, | ||
| especially if you run multiple sub-commands in a single request. For | ||
| example, this JSON request would provide most of the data you might | ||
| need in a single request: | ||
|
|
||
| {"command":"devs+summary+pools+devs2+summary2+pools2"} | ||
|
|
||
| Whenever a second algo isn't available, the three latter requests will | ||
| return "Invalid command" replies. |