diff --git a/README.md b/README.md index 805530a..ea22e55 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# teamredminer v0.9.1 +# teamredminer v0.9.2 This is an optimized miner for AMD GPUs and Xilinx FPGAs created by todxx and kerney666. **Download is available in the [github releases section](https://github.com/todxx/teamredminer/releases).** @@ -38,6 +38,7 @@ Supported GPU algorithms and their respective dev fees: | Kawpow | 2.0% | | Verthash | 2.0% | | Autolykos2 | 2.0% | +| Ton | 1.0% | | Nimiq | 2.5% | | Cryptonight R | 2.5% | | Cryptonight v8 upx2 | 2.5% | @@ -72,6 +73,7 @@ Some algorithms are not supported on some GPU architectures and/or drivers. Bel | Verthash | Y | Y | Y | Y | N | | Autolykos2 | Y | Y | Y | Y | Y | | Firopow | Y | Y | Y | Y | Y | +| Ton | Y | Y | Y | Y | Y | | Nimiq | Y | Y | Y | Y | N | | Cryptonight R | N | L | L | L | N | | Cryptonight v8 upx2 | N | L | L | L | N | @@ -128,6 +130,15 @@ For command line options see the [USAGE.txt](USAGE.txt) file that comes with the ## Release Notes +### v0.9.2 +#### Changes +- GPU: Added TON algo for single algo mining on all gpu generations (see TON_MINING.txt). +- GPU: Added dual ETH+TON mining for Navi and Big Navi gpus (see DUAL_ETH_MINING.txt). Vega and Polaris upcoming shortly. +- GPU: Added dual mining tuner based on scoring weights (see --dual_tuner_weights). +- GPU: Faster initial ethash tuning on startup. +- FPGA: Added --fpga_max_jtag_mhz for limiting the JTAG communication frequency used. +- FPGA: Fixed DNA for vu35p - now matches Vivado hardware manager and NextJTAG. + ### v0.9.1 #### Changes - FPGA: Updated FPGA_GUIDE.txt with new devices, voltage tuning, and more. diff --git a/USAGE.txt b/USAGE.txt index 6fb2913..060fe89 100644 --- a/USAGE.txt +++ b/USAGE.txt @@ -1,4 +1,4 @@ - Team Red Miner version 0.9.1 + Team Red Miner version 0.9.2 Usage: teamredminer [OPTIONS] Options: -a, --algo=ALGORITHM Selects the mining algorithm. Currently available: @@ -9,6 +9,7 @@ Options: mtp_firopow (chooses firopow or mtp and shuts down miner at the fork on Oct 26 2021) autolykos2 (ergo) verthash (vtc) + ton (ton) nimiq (nimiq) lyra2z phi2 (lux, argoneum) @@ -48,6 +49,11 @@ Options: decides the interface(s) and port to listen to. Default is 127.0.0.1:4028. For external access, use e.g. 0.0.0.0:4028. It's also valid to only specify the port, e.g. 4029. + --api2_listen=IP:PORT Enables a second api port for dual mining setups. This api endpoint will provide data for the + dual mining algo, just like if two separate miner instances were running in parallel. The + default setting is 127.0.0.1:4029, i.e. the port is 4029 and not 4028. For specifying your + own choice, the argument is formatted like --api_listen. + --cm_api_listen=IP:PORT Enables the claymore compatible api. IP:PORT is optional. If present, the IP:PORT combo decides the interface(s) and port to listen to. Default is 127.0.0.1:3333. For external access, use e.g. 0.0.0.0:3333. It's also valid to only specify the @@ -570,6 +576,51 @@ ZIL dual mining options: the ZIL mining. Some contexts might get confused by this if they are parsing the TRM outut or log files. To switch to the default output, add --stats_mode=single. +TON options: + --ton_pool_mode=X Specifies the TON mining dialect used. If not set, the miner will try to deduce the correct choice + from the pool hostname. Available options are: + toncoinpool - use the stratum wss protocol for toncoinpool. + icemining - use ice mining's stratum protocol over tcp/ip. + --wss_no_proxy Disables the automatic wss proxy executed as a separate process used for TON pools that run their + mining protocol over wss. This means that the host and port passed to the miner must be pointing + to a proxy. + --wss_proxy=VALUE Overrides the default path to the wss proxy. The default is trm_nimiq_proxy-win.exe and. + and trm_nimiq_proxy-linux in the current miner directory as it was originally only used for. + Nimiq. + --wss_port=VALUE Overrides the default local port (4444) used for the wss proxy. This can be used if your + system is already using port 4444 for some other tcp/ip service. + +TON dual mining options: + --ton_start or --ton Starts the TON dual mining config. Between this and the --ton_end marker, all arguments are + applied to the TON mining rather than the primary algo, typically ethash. It's expected that + ethash has been set up in earlier arguments. The intention is that you can add a --ton ... --ton_end + configuration to any working TRM configuration algo and things will work out of the box. + + The minimal working setup is to only provide a TON pool. Read the TON mining guide for info on + supported pools. This is an example for icemining, using its beta pool address: + --ton -o stratum+tcp://ton.hashrate.to:4003 -u . -p x --ton_end + + For more info, read the TON dual mining guide packaged with the TRM release. + + --ton_end Marks that we're done with the TON mining config and all following arguments are for the primary + algo. This argument isn't strictly necessary, but should be included for mining distros since + the user has no guarantee what arguments will be added automatically at the end of the command + line by the distro. + --dual_tuner_weights=X:Y:Z The dual mining tuner needs scoring weights for how much 1 MH/s of the primary and dual algo + are worth. There are defaults built into the miner that were valid when each algo was implemented + and added, but as network hashrates and market prices move, new values may need to be provided. + This argument provides three values, all expected to be positive numbers: + X Score for 1 MH/s of the primary algo (typically ethash). + Y Score for 1 MH/s of the secondary algo (typically TON). + Z Cost per 1 W of measured power. We recommend setting this to zero for now. + Example for ETH+TON: + + Based on manual relative value: each MH/s of ETH is worth 100 MH/s of TON + --dual_tuner_weights=100:1:0 + + Based on mining calculators: $0.0437 for 1 MH/s ETH, $0.0005476 for 1 MH/s TON + --dual_tuner_weights=0.0437:0.0005476:0 + FPGA Options: --fpga_devices=LIST Sets FPGA devices to use from detected list. LIST should be a comma separated list of either device indices or device DNAs as shown by --list_devices. @@ -601,4 +652,5 @@ FPGA Options: --fpga_allow_unsafe=LIST Disables default safety limits for the specified FPGAs. The devices are specified with a comma separated list of DNA values, e.g. --fpga_allow_unsafe=40020000013ae32135111111 ***** CAUTION: Running above safety limits can result in PERMANENT DAMAGE to the device! ***** + --fpga_max_jtag_mhz=XY.Z Sets the max allowed frequency to use for fpga jtag communication. Default is 30.0 MHz. diff --git a/doc/DUAL_ETH_MINING.txt b/doc/DUAL_ETH_MINING.txt new file mode 100644 index 0000000..153bf1c --- /dev/null +++ b/doc/DUAL_ETH_MINING.txt @@ -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 . -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 . -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. diff --git a/doc/TON_MINING.txt b/doc/TON_MINING.txt new file mode 100644 index 0000000..c90a86f --- /dev/null +++ b/doc/TON_MINING.txt @@ -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 . -p x + +Ton Coin Pool: -o stratum+tcp://pplns.toncoinpool.io:443/stratum -u -p + +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 . -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 -p + diff --git a/doc/TRM_DUAL_MINING_API.txt b/doc/TRM_DUAL_MINING_API.txt new file mode 100644 index 0000000..c0ea94d --- /dev/null +++ b/doc/TRM_DUAL_MINING_API.txt @@ -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.