decred / gominer Goto Github PK

View Code? Open in Web Editor NEW

This project forked from dirbaio/gominer

159.0 20.0 77.0 547 KB

Go (golang) based GPU miner for Decred.

License: GNU General Public License v3.0

C 59.75% Go 38.63% Cuda 1.57% Shell 0.05%

go golang cuda opencl amd nvidia intel gpu stratum mining cryptocurrency miner decred

gominer's People

Contributors

Stargazers

Watchers

Forkers

jcvernaleo cjepson chappjc dajohi jrick marcopeereboom staskoval ztnbot guangminglion fuksito lcpo cardinalproperty myholyrose mramshaw scryptolabs luxorlabs acamtech jdave9036 jamiekeefer birdayz x2cn quiz42 skimoo longniao romangrechin hybridnetwork mc-aeq haigame coderbradlee wadewill mraaroncruz w1r2p1 sh1nu11bi dnldd coolsnady chainchip vanjames tonyli2377 mygirl8893 s-ben thankst allchain cryptojef attackgithub isgasho marciopocebon nextdesignsolutions tuxcanfly tynes dolanor-galaxy themanulfull tatdig dongpu1813 alenny811 soitun prosandcons gushou strategist922 tjaxer douglasnbk maximicciullo go-inspire bubonik666 bobo-boom benrod3k perrywliu istocko jholdstock adrielvelazquez davecgh matheusd chinaob awshrb mcmhg gddrig nevata git-drhardware

gominer's Issues

solo mining on CUDA triggers hardware error warnings

Noticed that while solo mining on testnet, I see a fairly steady stream of hardware error warnings.

I've never seen this while pool/stratum mining. This definitely doesn't seem to be a legitimate hardware error since if I change the pool mining card to stratum mining and vice versa, it only happens on whatever GPU is doing solo mining.

Need to check if this happens on mainnet too.

Not very familiar with the CUDA code but might be a regression from #108 or #116 since I don't remember seeing it when initial CUDA support landed. Could also possibly be related to #121.

investigate memory leak in OpenCL code

gominer has a small memory leak under normal usage that grows over time.

With a tiny worksize where it runs through the OpenCL loop hundreds of times per second, it will leak a few MB in seconds.

Need to add some debug code to find the size of the leak and then pinpoint where exactly it's occurring.

Stratum and work updates are super racy

Updates and retrieval of the data in both stratum struct fields and work struct fields should be subject to a mutex to prevent racing, which may occasionally cause rejects of valid work or the GPU to work on corrupted work.

div by zero panic

After about 1 hour of running I hit this pretty consistently:

23:02:18 2016-07-26 [INF] MINR: GPU #0 (Intel(R) HD Graphics Haswell GT2 Desktop) reporting average hash rate 24MH/s, 20/20 valid work
panic: division by zero

goroutine 38 [running]:
panic(0x8c7020, 0xc820473930)
        /home/jcv/code/golang/src/runtime/panic.go:481 +0x3e6
math/big.nat.div(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc8200163c0, 0x4, 0x8, 0x0, ...)
        /home/jcv/code/golang/src/math/big/nat.go:522 +0xc0
math/big.(*Int).QuoRem(0xc8203980e0, 0xc820012740, 0xc8204bf528, 0xc8204bf4c8, 0x0, 0x0)
        /home/jcv/code/golang/src/math/big/int.go:227 +0xe6
math/big.(*Int).Div(0xc8203980e0, 0xc820012740, 0xc8204bf528, 0xc820473920)
        /home/jcv/code/golang/src/math/big/int.go:238 +0x60
main.diffToTarget(0x3fe0000000000000, 0x8c0320)
        /home/jcv/code/go/src/github.com/decred/gominer/stratum.go:968 +0x9b
main.(*Stratum).Unmarshal(0xc82043a000, 0xc8203e9f80, 0x3e, 0x40, 0x0, 0x0, 0x0, 0x0)
        /home/jcv/code/go/src/github.com/decred/gominer/stratum.go:670 +0x42f6
main.(*Stratum).Listen(0xc82043a000)
        /home/jcv/code/go/src/github.com/decred/gominer/stratum.go:254 +0x89b
created by main.StratumConn
        /home/jcv/code/go/src/github.com/decred/gominer/stratum.go:181 +0x5df

Investigate high CPU usage on CUDA

And fix it...

add windows build instructions to README

For AMD using TDM from @cjepson

install app sdk
install newest golang
install tdm gcc
surf to the gominer directory in the tdm gcc cmd
change directories and run:
set CGO_CFLAGS=-IC:/appsdk/include && set CGO_LDFLAGS=-LC:/appsdk/lib/x86_64 && go build -x -v

Probably want to add an Nvidia example too.

sample config needs to be updated with all the new options

go lintify

This will bring the API to proper Go syntax.

properly deal with multiple OpenCL run-times

@tpruvot noticed that with multiple OpenCL run-times installed, gominer only properly detects the 1st OpenCL platform.

Can install http://portablecl.org/ or something for testing.

Use glide for deps

We should use glide for our deps (at least the go ones) the way all the other dcr projects do.

Seperate builds

Currently, to build, one needs both opencl and cuda libs installed. We should split this up (most of the code is already separate) and use go build flags to only include what is needed.

sample config needs updating

gominer speed

Currently gominer (opencl) performs 20% or so slower than the other miners on the same hardware.

@jolan at some point could you provide real numbers for this.

Clearly, we should get this much closer. Since the heavy lifting is not done in go, go vs c/c++ speed should not really matter here.

investigate high CPU/memory usage

There has been complaints about both excessive memory and CPU usage. The ability to create and dump profiles should be added.

Add to cuda LDFLAGS

Additional LDFLAGS are needed for building on things other than archlinux.
We need the default flags: -L/opt/cuda/lib64 -L/usr/local/cuda/lib64
Ubuntu ones
Windows ones.

GPU errors

I've only hit this on Intel GPUs (so nothing production worthy) so it isn't super important but still worth considering.
If there is an error on the GPU, gominer will stop working on that GPU and just keep chugging along. If only one GPU is in use, the program will not stop but will not do any useful work.
I'm not sure if it should try to recover and restart, but at the very least if there are no active GPUs it should exit. The only thing stopping this is that the list of GPUs ends up numbered wrong if we remove bad ones and the work thread lacks a way to tell the main thread that it is done.
Again, this is very not vital unless we see things on more powerful GPUs.

Outdated comments in cudevices.go

Improve new work handling

We can probably handle new work from a pool better (when does code notice, when do we start on the new work, etc.).

Add opencl instructions to windows readme

Please add instructions to build opencl on windows.

No suitable hashes found when pool mining

When mining on a stratum pool, despite matching the getwork generated by other miners, gominer never finds an appropriate hash.
@jolan can you add some more details here?

implement fan/temperature control in supported backends

amdgpu
NVML (unsupported but need to error properly when flags are set)
ADL

reject counter not incremented

14:29:05 2016-07-27 [ERR] POOL: Share rejected: job not found
14:29:07 2016-07-27 [INF] MINR: Global stats: Accepted: 4602, Rejected: 0, Stale: 111

json unmarshal error on stratum pool share rejection

18:48:42 2016-08-15 [ERR] POOL: json: cannot unmarshal array into Go value of type stratum.StratErr
18:48:42 2016-08-15 [ERR] POOL: Share rejected: job not found

Investigate high CPU usage on opencl

Fix it.

implement device selection

It's pretty common to have a weak GPU for desktop use and more powerful cards for mining use.

This is also a feature universally provided by every other miner.

CUDA support

gominer currently only supports opencl. To get the best performance on more gpus, CUDA support should be added.
Mostly this would involve the cgo bindings in gominer/cl and the actual calls in device.go (maybe device_cuda, device_cl or something like that with the main device being totally generic but that needs a little thought).

do performance testing/comparisons

Have done some performance comparisons in the past but not long enough to have a high degree of accuracy.

Will perform 24h pool/testnet solo-mining tests and add the results to the README.

Requested by @behindtext

log output

The log output (particularly DEBUG and TRACE) have very little order to them. We need to put most useful things in DEBIUG (like json messages) and any of the other stuff only interesting to devs in TRACE or something similar to that. There might also be some duplicate logging.
INFO and ERROR log levels should be in pretty good shape.

Output line is very long

The normal (INFO) log output from gominer is very long. Can at least remove the word reporting so terminal doesn't have to be a wide.

starting up: invalid memory address or nil pointer dereference

Dual AMD GPU: R9 290x and R9 280x.
Started with -B to benchmark. Crashes as regular user or root.
sgminer runs fine.

01:02:59 2016-08-03 [INF] MAIN: Version 0.2.0-beta
01:03:02 2016-08-03 [INF] MINR: GPU #0: Work size set to 666430208 ('intensity' 29.31187855587688)
01:03:03 2016-08-03 [INF] MINR: GPU #1: Work size set to 910539008 ('intensity' 29.762145583486816)
01:03:03 2016-08-03 [WRN] MINR: Running in BENCHMARK mode! No real mining taking place!
01:03:03 2016-08-03 [INF] MINR: Global stats: Accepted: 0, Rejected: 0, Stale: 0
01:03:03 2016-08-03 [INF] MINR: GPU #0 (Tahiti) reporting average hash rate 0H/s, 0/0 valid work
01:03:03 2016-08-03 [INF] MINR: GPU #1 (Hawaii) reporting average hash rate 0H/s, 0/0 valid work
01:03:03 2016-08-03 [INF] MINR: Started GPU #0: Tahiti
01:03:03 2016-08-03 [INF] MINR: Started GPU #1: Hawaii
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0 pc=0x56d674]

goroutine 53 [running]:
panic(0x96abe0, 0xc82000e110)
    /usr/lib/go/src/runtime/panic.go:481 +0x3e6
math/big.(*Int).Cmp(0xc8203c0f80, 0x0, 0xffffffffffffffff)
    /usr/lib/go/src/math/big/int.go:314 +0x24
main.(*Device).foundCandidate(0xc82042a000, 0x4022c800000000, 0x3000000)
    /home/jon/go/src/github.com/decred/gominer/device.go:483 +0x652
main.(*Device).runDevice(0xc82042a000, 0x0, 0x0)
    /home/jon/go/src/github.com/decred/gominer/device.go:451 +0xdb5
main.(*Device).Run(0xc82042a000)
    /home/jon/go/src/github.com/decred/gominer/device.go:305 +0x28
main.(*Miner).Run.func1(0xc82042a000, 0xc820428cb0)
    /home/jon/go/src/github.com/decred/gominer/miner.go:272 +0x21
created by main.(*Miner).Run
    /home/jon/go/src/github.com/decred/gominer/miner.go:275 +0xc1

remove code duplication/improve build system

A lot of code is duplicated between cladldevice.go/cldevice.go/cudevice.go to work around having hard run-time dependencies on libraries. Should be able to reduce this somehow.

Occasional negative WaitGroup counter on CTRL+C

Occasionally, when CTRL+C is hit, you get the following panic:

14:21:15 2016-08-09 [WRN] MAIN: Got Control+C, exiting...
panic: sync: negative WaitGroup counter

goroutine 11 [running]:
panic(0x89ca20, 0xc082454250)
        C:/Go/src/runtime/panic.go:481 +0x3f4
sync.(*WaitGroup).Add(0xc082010f80, 0xffffffffffffffff)
        C:/Go/src/sync/waitgroup.go:71 +0xd7
sync.(*WaitGroup).Done(0xc082010f80)
        C:/Go/src/sync/waitgroup.go:96 +0x31
main.(*Miner).workRefreshThread(0xc082010f50)
        C:/building/go/src/github.com/decred/gominer/miner.go:255 +0x270
created by main.(*Miner).Run
        C:/building/go/src/github.com/decred/gominer/miner.go:318 +0x3fa

Fix size of data copied from device

implement amdgpu support

Catalyst+ADL on Linux is deprecated in favor of amdgpu's sysfs interface.

So ADL support in #62 won't complete fan control for AMD cards.

Make stratum code into a package

The stratum code (all in stratum.go) should be moved into a package of its own. This will be cleaner and make it easier to add other pools.
The one issue is the code depends on the Work type from main which forces them to be in the main package. We could put Work in a package of its own but it seems odd to have a package for one type. Might be other things that could reasonably go there. This is not needed for things to work but will be needed before adding other pool types. Very easy but requires a decision.

implement CUDA support

This was mentioned in RFP-5.

Performance numbers

ccminer vs gominer using both opencl & cuda.

We need to know where we are at on these. Please provide a matrix of soft- and hardware and run several tests to obtain an average value. Obviously we don't have cuda on gominer yet so that can be skipped for now.

Make gominer CUDA work on windows

CUDA on windows uses VS2013 as its backend and requires a bunch of magic to make it work with cgo.

Implement and document this.

implement ADL support

This was mentioned in RFP-5.

http://developer.amd.com/tools-and-sdks/graphics-development/display-library-adl-sdk/

gominer crashes when an invalid target is recieved

The code correctly catches invalid targets but doesn't stop the rest of the code from trying to work on it (leading to a panic when it tries to access the target).
This is only likely to be hit on very slow cards.

Use more optimized opencl code

https://github.com/decred/cgminer has a newer and more optimized blake256 opencl kernel. It would be nice to use this for gominer but it currently panics on benchmark. This is because the format of the output buffer is slightly different.

speed of non-gpu parts

The file https://github.com/decred/gominer/blob/master/blake256/blake256block.go
does a blake256 hash in go. As the comments in the file says, this is probably slow and very likely needs to be replaced with C or something fast if we want to get this up to the speed of other miners.

Unit tests needed.

gominer needs unit tests (run with go test).

Since we have broken things up into packages this shouldn't be as hard as it would have been for the initial code base.

There is already test data for foundCandidate in an unused test function in the code. That is probably one of the first that should be hit.

Remove vestigal code

There are a number of functions and definitions (both in cuda and in device.go) that are no longer used or were copied from ccminer and were never used. These should be removed.

implement NVML support

This was mentioned in RFP-5.

https://developer.nvidia.com/nvidia-management-library-nvml

go generate

There is a makefile to build some of the cuda code. This can probably be done with go generate instead.

high CPU usage while solo mining

pool/stratum mining CPU usage is steady at ~1-2% for both CUDA and OpenCL.

However, CPU usage while solo mining on testnet is:

~8% for OpenCL
~45% for CUDA

For OpenCL, I think this is in part due to how it works. It returns any diff 1 shares and then the difficulty is checked on the CPU. With lots of false positives per second, this is kind of to be expected.

Not sure about CUDA since I'm not very familiar with that yet.

Need to see if mainnet reveals similar results.

some shares go unaccounted

[INF] MINR: Global stats: Accepted: 8504, Rejected: 23, Stale: 163
[INF] MINR: Global utility (accepted shares/min): 1.4644604853407575
[INF] MINR: DEV #1 (Hawaii) reporting average hash rate 1.722GH/s, 8735/8735 valid work

8735 - 8504 - 23 - 163 = 45 or .52%

I haven't caught this with trace on but I did notice:

[INF] POOL: Unhandled message: {"id":8732,"result":true,"error":null}

I think this only happens when you find and submit shares in short order. Probably something like:

Share 1 is submitted
Share 2 is submitted
Share 1 reply received (unhandled and unaccounted)
Share 2 reply received

So I think we just need to save the previous submit as well as the current submit.

Autocalibration option should be per-gpu

Just like work size and intensity, autocalibration should be a per-gpu setting. The best value is quite different for dissimilar chips.

Panic when miner can't start

If mining can't start due (for example no permission to use the GPU) gominer panics. It should error gracefully with some sort of message:

20:03:59 2016-08-02 [WRN] MAIN: open /home/jcv/.gominer/gominer.conf: no such file or directory
20:03:59 2016-08-02 [INF] MAIN: Version 0.2.0-beta
No protocol specified
Error: No root privilege. Please check with the system-admin.
Error: No root privilege. Please check with the system-admin.
No protocol specified
No protocol specified
Error: No root privilege. Please check with the system-admin.
Error: No root privilege. Please check with the system-admin.
20:03:59 2016-08-02 [INF] POOL: Using pool: stratum+tcp://yiimp.ccminer.org:4252
No protocol specified
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x0 pc=0x7fe8381172fb]

runtime stack:
runtime.throw(0xcaca60, 0x2a)
    /home/jcv/code/golang/src/runtime/panic.go:547 +0x90
runtime.sigpanic()
    /home/jcv/code/golang/src/runtime/sigpanic_unix.go:12 +0x5a

goroutine 1 [syscall, locked to thread]:
runtime.cgocall(0xa0e160, 0xc8203f5aa0, 0x0)
    /home/jcv/code/golang/src/runtime/cgocall.go:123 +0xc2 fp=0xc8203f5a50 sp=0xc8203f5a28
github.com/decred/gominer/cl._Cfunc_clGetPlatformIDs(0xc800000000, 0x0, 0xc820462490, 0xc800000000)
    ??:0 +0x61 fp=0xc8203f5aa0 sp=0xc8203f5a50
github.com/decred/gominer/cl.CLGetPlatformIDs(0x0, 0x0, 0x0, 0x0, 0xc8203f5b94, 0xc82044a000)
    /home/jcv/code/go/src/github.com/decred/gominer/cl/platform.go:34 +0xce fp=0xc8203f5b60 sp=0xc8203f5aa0
main.getCLPlatforms(0x0, 0x0, 0x0, 0x0, 0x0)
    /home/jcv/code/go/src/github.com/decred/gominer/miner.go:19 +0x77 fp=0xc8203f5bc8 sp=0xc8203f5b60
main.NewMiner(0xc82007bda8, 0x0, 0x0)
    /home/jcv/code/go/src/github.com/decred/gominer/miner.go:78 +0x520 fp=0xc8203f5e08 sp=0xc8203f5bc8
main.gominerMain(0x0, 0x0)
    /home/jcv/code/go/src/github.com/decred/gominer/main.go:75 +0x7c0 fp=0xc8203f5f20 sp=0xc8203f5e08
main.main()
    /home/jcv/code/go/src/github.com/decred/gominer/main.go:99 +0x38 fp=0xc8203f5f48 sp=0xc8203f5f20
runtime.main()
    /home/jcv/code/golang/src/runtime/proc.go:188 +0x247 fp=0xc8203f5f90 sp=0xc8203f5f48
runtime.goexit()
    /home/jcv/code/golang/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc8203f5f98 sp=0xc8203f5f90

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /home/jcv/code/golang/src/runtime/asm_amd64.s:1998 +0x1

goroutine 20 [semacquire]:
sync.runtime_Syncsemacquire(0xc8200716d0)
    /home/jcv/code/golang/src/runtime/sema.go:241 +0x201
sync.(*Cond).Wait(0xc8200716c0)
    /home/jcv/code/golang/src/sync/cond.go:63 +0xb3
github.com/decred/gominer/vendor/github.com/btcsuite/seelog.(*asyncLoopLogger).processItem(0xc82006e7e0, 0x0)
    /home/jcv/code/go/src/github.com/decred/gominer/vendor/github.com/btcsuite/seelog/behavior_asynclooplogger.go:50 +0x179
github.com/decred/gominer/vendor/github.com/btcsuite/seelog.(*asyncLoopLogger).processQueue(0xc82006e7e0)
    /home/jcv/code/go/src/github.com/decred/gominer/vendor/github.com/btcsuite/seelog/behavior_asynclooplogger.go:63 +0x4b
created by github.com/decred/gominer/vendor/github.com/btcsuite/seelog.newAsyncLoopLogger
    /home/jcv/code/go/src/github.com/decred/gominer/vendor/github.com/btcsuite/seelog/behavior_asynclooplogger.go:40 +0xd7

goroutine 21 [semacquire]:
sync.runtime_Syncsemacquire(0xc820071850)
    /home/jcv/code/golang/src/runtime/sema.go:241 +0x201
sync.(*Cond).Wait(0xc820071840)
    /home/jcv/code/golang/src/sync/cond.go:63 +0xb3
github.com/decred/gominer/vendor/github.com/btcsuite/seelog.(*asyncLoopLogger).processItem(0xc82006e900, 0x0)
    /home/jcv/code/go/src/github.com/decred/gominer/vendor/github.com/btcsuite/seelog/behavior_asynclooplogger.go:50 +0x179
github.com/decred/gominer/vendor/github.com/btcsuite/seelog.(*asyncLoopLogger).processQueue(0xc82006e900)
    /home/jcv/code/go/src/github.com/decred/gominer/vendor/github.com/btcsuite/seelog/behavior_asynclooplogger.go:63 +0x4b
created by github.com/decred/gominer/vendor/github.com/btcsuite/seelog.newAsyncLoopLogger
    /home/jcv/code/go/src/github.com/decred/gominer/vendor/github.com/btcsuite/seelog/behavior_asynclooplogger.go:40 +0xd7

goroutine 22 [syscall]:
os/signal.signal_recv(0x48c481)
    /home/jcv/code/golang/src/runtime/sigqueue.go:116 +0x132
os/signal.loop()
    /home/jcv/code/golang/src/os/signal/signal_unix.go:22 +0x26
created by os/signal.init.1
    /home/jcv/code/golang/src/os/signal/signal_unix.go:28 +0x45

goroutine 4 [chan receive]:
github.com/decred/gominer/vendor/github.com/btcsuite/seelog.(*asyncAdaptiveLogger).processQueue(0xc8200a2180)
    /home/jcv/code/go/src/github.com/decred/gominer/vendor/github.com/btcsuite/seelog/behavior_adaptivelogger.go:127 +0xac
created by github.com/decred/gominer/vendor/github.com/btcsuite/seelog.newAsyncAdaptiveLogger
    /home/jcv/code/go/src/github.com/decred/gominer/vendor/github.com/btcsuite/seelog/behavior_adaptivelogger.go:84 +0x6a9

goroutine 25 [IO wait]:
net.runtime_pollWait(0x7fe838b3a828, 0x72, 0x43e0c9)
    /home/jcv/code/golang/src/runtime/netpoll.go:160 +0x63
net.(*pollDesc).Wait(0xc820478140, 0x72, 0x0, 0x0)
    /home/jcv/code/golang/src/net/fd_poll_runtime.go:73 +0x56
net.(*pollDesc).WaitRead(0xc820478140, 0x0, 0x0)
    /home/jcv/code/golang/src/net/fd_poll_runtime.go:78 +0x44
net.(*netFD).Read(0xc8204780e0, 0xc8204b4000, 0x1000, 0x1000, 0x0, 0x7fe83ce48000, 0xc820074000)
    /home/jcv/code/golang/src/net/fd_unix.go:250 +0x27b
net.(*conn).Read(0xc82044a000, 0xc8204b4000, 0x1000, 0x1000, 0xc82002d000, 0x0, 0x0)
    /home/jcv/code/golang/src/net/net.go:172 +0x121
net.(*TCPConn).Read(0xc82044a000, 0xc8204b4000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
    <autogenerated>:68 +0x7d
bufio.(*Reader).fill(0xc8204b2000)
    /home/jcv/code/golang/src/bufio/bufio.go:97 +0x365
bufio.(*Reader).ReadSlice(0xc8204b2000, 0xa, 0x0, 0x0, 0x0, 0x0, 0x0)
    /home/jcv/code/golang/src/bufio/bufio.go:328 +0x5a9
bufio.(*Reader).ReadBytes(0xc8204b2000, 0xc820074f0a, 0x0, 0x0, 0x0, 0x0, 0x0)
    /home/jcv/code/golang/src/bufio/bufio.go:406 +0xc0
bufio.(*Reader).ReadString(0xc8204b2000, 0xc820074f0a, 0x0, 0x0, 0x0, 0x0)
    /home/jcv/code/golang/src/bufio/bufio.go:446 +0x5b
github.com/decred/gominer/stratum.(*Stratum).Listen(0xc82007a000)
    /home/jcv/code/go/src/github.com/decred/gominer/stratum/stratum.go:255 +0x1c2
created by github.com/decred/gominer/stratum.StratumConn
    /home/jcv/code/go/src/github.com/decred/gominer/stratum/stratum.go:201 +0xa51

decred / gominer Goto Github PK

gominer's People

Contributors

Stargazers

Watchers

Forkers

gominer's Issues

Recommend Projects

Recommend Topics

Recommend Org