etherchain-org/qtminer

Stratum enabled Ethereum miner

qtminer

Stratum enabled Ethereum miner

qtminer's Issues

POST on new work

Send HTTP POST to a configured list of URL when a new work package is available

qtminer stopped mining out of the blue

qtminer all of a sudden stopped mining. I tried following to get it working again:

• Remove DAG files
• Reboot computer

With the below batchfile it has been working for hours yesterday untill my GPU fan stopped blowing, which triggered me to have a look.

Is there anything I can do to debug?

It now just keeps hanging at when relaunching:

C:\qtminer>ethermine.org.bat

C:\qtminer>setx GPU_FORCE_64BIT_PTR 0

SUCCESS: Specified value was saved.

C:\qtminer>setx GPU_MAX_HEAP_SIZE 100

SUCCESS: Specified value was saved.

C:\qtminer>setx GPU_USE_SYNC_OBJECTS 1

SUCCESS: Specified value was saved.

C:\qtminer>SET GPU_SINGLE_ALLOC_PERCENT=100

C:\qtminer>qtminer.exe -s eu1.ethermine.org:4444 -u 0xF34bbccBe84f540EBa4d06C618d53D67a114fbFE.rig1 -G
Qt: Untested Windows version 10.0 detected!
  i  09:59:13|main  Connecting to stratum server eu1.ethermine.org : 4444
  i  09:59:13|main  Connection to stratum server established!
Found suitable OpenCL device [Bonaire] with 2147483648 bytes of GPU memory
  i  09:59:13|main  Login to stratum server successfull
  i  09:59:13|main  Work package received
  i  09:59:13|main  Grabbing DAG for #151f7216
  i  09:59:14|<unknown>  Loading full DAG of seedhash: #a1cf1239
  i  09:59:14|main  Got work package:
  i  09:59:14|main    Header-hash: ed4b4602ccfcd94c0db86fb67ce098f9accf646ac42d46a81aeedc882b7c0123
  i  09:59:14|main    Seedhash: 151f7216ab91b503676b2e3ee43f0ec27dda59f863ceafda5bfac3cc5b3afad9
  i  09:59:14|main    Target: 0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba
  i  09:59:14|gpuminer0  workLoop 0 #00000000 #151f7216
  i  09:59:14|main  Push: New work package received
  i  09:59:14|gpuminer0  Initialising miner...
  i  09:59:15|main  Got work package:
Using platform: AMD Accelerated Parallel Processing
  i  09:59:15|main    Header-hash: efaf3076c61713313c8b565e591cf51a28c902bf3955d6042da924e21f576a0b
Using device: Bonaire(OpenCL 2.0 AMD-APP (1800.5))
  i  09:59:15|main    Seedhash: 151f7216ab91b503676b2e3ee43f0ec27dda59f863ceafda5bfac3cc5b3afad9
  i  09:59:15|main    Target: 0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba

QtMiner.h: No such file or directory included

Is there any documentation on how to compile?

On linux mint 17.3 (ubuntu 14.04.3), I tried

QtMiner.h: No such file or directory
 #include "QtMiner.h"

This resulted in the error

main.cpp:1:21: fatal error: QtMiner.h: No such file or directory
 #include "QtMiner.h"
                     ^
compilation terminated.
qtminer.cpp:1:21: fatal error: QtMiner.h: No such file or directory
 #include "QtMiner.h"
                     ^
compilation terminated.

can only mine using all GPUS or 1. Cant' use more than one but less than all

I have 3 GPU's in my system. I want to mine using qtminer with devices 0 and devices 1 not device 2
I noticed that the switch --opengl-device can only be 1 number. Therefore it is not possible to mine using two devices only.

ethminer -G --opengl-devices 0 1

qtminer keeps crashing on startup, until randomly it decides to work again

Just as in the title.
Recently, I've noticed that qtminer is not starting up reliably. It will keep crashing with the "QtMiner.exe stopped working" error over and over. The log just before each crash looks like this (the last line isn't a copy-paste error - it's exactly how it appears in the console):

C:\Program Files\Mist\qtminer>qtminer.exe -s pool.alpereum.ch:3002 -u 0xdD7EB7EB937CA864520A9490248eb0a215B3C339.rx480 -G
Qt: Untested Windows version 10.0 detected!
i 02:50:58|main Connecting to stratum server pool.alpereum.ch : 3002
i 02:50:58|main Connection to stratum server established!
Found suitable OpenCL device [Ellesmere] with 4294967296 bytes of GPU memory
i 02:50:59|main Login to stratum server successfull
i 02:50:59|main Push: New work package received
i 02:50:59|main Grabbing DAG for #7c4fb8a5ÔÇŽ
i 02:51:00|main Got work package:
i 02:51:00| Loading full DAG of seedhash: #3868abc5ÔÇŽ
i 02:51:00|main Header-hash: bb63442d61ecbe2e21b11d0872d8ce761f5d528b86f534ba54debcc87f4aa229
i 02:51:00|main Seedhash: 7c4fb8a5d141973b69b521ce76b0dc50f0d2834d817c7f8310a6ab5becc6bb0c
i 02:51:00|main Target: 0000000225c17d04dad2965cc5a02a23e254c0c3f75d9178046aeb27ce1ca574
i 02:51:00|gpuminer0 workLoop 0 #00000000ÔÇŽ #7c4fb8a5ÔÇŽ
i 02:51:00|gpuminer0 Initialising miner...
i 02:51:00|main Work package received
i 02:5

It will crash several times (sometimes 2-3 times, sometimes even like 20), but eventually it'll snap and it will just start mining properly.
Here's an extract from the event viewer: qtminer.zip
Worth noting: this happens on both of my computers. The main one runs Windows 10 1703 x64 with an RX 480. The secondary one runs Windows Server 2012 x64, with an R9 280X.

Add makefile

Hi, could you make life more fun and add a makefile for me? ;-)

cheers

--list-devices flag does not output devices on windows

C:\Users\User\qtminer>QtMiner.exe --list-devices
Qt: Untested Windows version 10.0 detected!
Usage: QtMiner.exe [options]
Stratum enabled ethereum miner

Options:
  -?, -h, --help            Displays this help.
  -v, --version             Displays version information.
  -s, --server <server>     Stratum server host (e.g. ethpool.org:3333)
  -u, --user <user>         Username
  -p, --pass <pass>         Password
  -G, --gpu                 When mining use the GPU via OpenCL.
  --opencl-platform <n>     When mining using -G/--opencl use OpenCL platform n
                            (default: 0).
  --opencl-device <n>       When mining using -G/--opencl use OpenCL device n
                            (default: 0).
  -t, --mining-threads <n>  Limit number of CPU/GPU miners to n (default: use
                            everything available on selected platform).
  --list-devices            List the detected OpenCL devices and exit.
  --current-block <n>       Let the miner know the current block number at
                            configuration time. Will help determine DAG size and
                            required GPU memory.
  --cl-extragpu-mem <n>     Set the memory (in MB) you believe your GPU
                            requires for stuff other than mining. Windows
                            rendering e.t.c..
  --cl-local-work <n>       Set the OpenCL local work size. Default is 64.
  --cl-global-work <n>      Set the OpenCL global work size as a multiple of
                            the local work size. Default is 4096 * 64
  --ms-per-batch <n>        Set the OpenCL target milliseconds per batch
                            (global workgroup size). Default is 0. If 0 is given
                            then no autoadjustment of global work size will
                            happen.
  --no-precompute           Don't precompute the next epoch's DAG.

I have an nvidia card and onboard graphics, and need to know the device number of my nvidia card, because qtminer defaults to the intel graphics

Blockchain Formation qtminer: Performance

I'm in processing reading your code ( more to come once I have more time to write all my observations).

As now Farm from C++ Ethereum is used throught QT Signal and Slot ( this needs more deep reading). Using them instead of while and loop in doFARM function in class MinerAux seems a very good alternative. Also the encapsulation of the solution process inside the Lambda function is very neat.

However a potential issue remains always: the current work-package will be updated while the solution is processed in the Lambda. The functor passed into f.onSolutionFound will use an argument sol which is indeed the right solution for the "current" ... The only big problem is in the mean-time the "current" have been updated by a new workplace and it's a "new current" not really associated to the founded argument sol ... Your emit solutionFound () has two data the sol for the old current mixed with the new updated current.

I will have more details about this once I finish my total review of the used alternatives ( QTimer and so on.). Qtimer's accuracy and sensitivity will certainly depend on the underlying operating system and hardware and also on the nature of the current update and the used mining process.

I got a long discussion with Go Ethereum about how eth_getwork is working, see
https://gitter.im/ethereum/go-ethereum, spot efaysal oct 06 02:09.

JSON RPC eth_getWork returns the hash of the current block, the seedHash, and the boundary condition to be met ("target"). This function is used in C++ Ethereum to update the workpackage and it's only Go-implemented or coded. The "current block" is NOT necessarily the network’s current block.

The elimination of the while(true) and loop is a fact now, you can just suppress this

unsigned _recheckPeriod = 500;

Try to have a look into ethereum/aleth#2985

An analysis have been conducted to figure out the effect of _recheckPeriod. As now is not used any more that may be good for the performance.

Also:

In the function overrided function workLoop() in Class EthashCPUMiner, the nonce initialized randomly :
uint64_t tryNonce = (uint64_t)(u64)Nonce::random(s_eng);

In the loop the nonce will be incremented till a solution is defined.

Why the trynonce is not again selected randomly inside the loop instead of just incrementing by one?

In Go Ethereum, the nonce is defined randomly as
sha := uint64(r.Int63())
if verify(hash, diff, sha)

inside a loop incremented using a start i := rand.Int63(), starti := i, but the nonce is defined randomly!

Here, why Go and C++ used two ways to define the nonce, which one is providing worst performance or better performance?

It's better to override that function and make the nonce selected randomly. It's very important for the performance of the pool, as each miner is mining using a random nonce. If the nonce is just incremented, it may happen that many of the miners are overlapping their calculations in vain.

Let's give an example, 3 miners in your pool working on the same workpackage:

Miner_1 used nonce 1, and is incrementing it till a solution will be reach.

Miner_2 used nonce 2 =nonce 1 + some number, and is incrementing it till a solution will be reach.

Miner_3 used nonce 3 =nonce 2 + some number, and is incrementing it till a solution will be reach.

Assume that the right nonce is greater than nonce 3. Using incrementation, the miner's performance is mainly depending on the first random draw of the nonce and the incrementation is not necessary working for the best performance, Miners 1 and 2 have to overcome many incrementation to reach the right nonce which is greater than nonce 3 > nonce 2 > nonce 1.

Miner 3 is more lucky with the incrementation.

In general, if the nonce is randomly selected, the miner is not trapped in a narrow specific incrementation that only depend on the first draw ...

I will add more comments as soon as I have a holistic review of all the designed points.