miniZv2.3c Equihash144,5 125,4 210,9 150,5 192,7 Beam ProgPoW Ethash CFX KLS PYI

[miniZ]

With the latest nVidia driver (460.79) I get this on Windows 10 and latest miniZ:

"Cannot read health status! (is libnvidia-ml.so installed?): No such file or directory"

"Sol/W=inf"

457.51 worked fine.

What gives?

Hi cryptosize,

You get that error when miniZ cannot find nvml.dll.

The file should be on the standard Windows locations, in \PROGRAM FILES\\NVIDIA Corporation\\NVSMI\\nvml.dll.
Or in the miniZ folder.

Where do you have this file?

Cheers

[1714711247]

1714711247

[1714711247]

1714711247

[1714711247]

1714711247

[cryptosize]

With the latest nVidia driver (460.79) I get this on Windows 10 and latest miniZ:

"Cannot read health status! (is libnvidia-ml.so installed?): No such file or directory"

"Sol/W=inf"

457.51 worked fine.

What gives?

Hi cryptosize,

You get that error when miniZ cannot find nvml.dll.

The file should be on the standard Windows locations, in \PROGRAM FILES\\NVIDIA Corporation\\NVSMI\\nvml.dll.
Or in the miniZ folder.

Where do you have this file?

Cheers

I'm not sure, maybe nVidia changed the dll location in 460 branch?

[cryptosize]

@miniZ

Can you try this driver yourself? https://www.nvidia.com/en-us/drivers/results/167421/

[joseph32]

@miniZ

Can you try this driver yourself? https://www.nvidia.com/en-us/drivers/results/167421/

Right now, none of the popular miners will work with the newest Nvidia driver version. Latest 457.51 is working. The windows version doesnt matter, from 1909 up to the newest 2H20.

[tymeksm]

Hi again

I found the problem with API..but do not know whats the reason.

On Ubuntu 16 and 18 works ok, but under Ubuntu 20 there is a problem...but only sometimes - not stable API

I use this method to retrive JSON data:
curl -s http://127.0.0.1:20000/getstat

but under ubuntu20 this act like this:
- very often give just no output (empty string)
in this same time respond with HTML page if request with:
curl -s http://127.0.0.1:20000/
gives full html page
- after some period of time api freezes and hangs every connection (both of avobe). Must enter Ctrl+C to back to bash
- only sometimes after few miner restarts work ok, and respond with JSON data.

Could you try the following :
curl http://localhost:20000/getstat -s --http0.9

Curl has been modified in Ubuntu 20.

Thanks. It works ok ;-)
I didnt know about this curl change. Thanks for info.
Other miners (API) seems to work fine under Ub20.
I had similar problem when migrating from Ub16 to Ub18 - need add "-q" to all nc requests to get work on Ub18

Now I find another method to get API JSON data from your miner (miniz), and seems to work well on all of Ubuntu 16/18/20 ;-)
echo '{"id":"0", "method":"getstat"}' | timeout 5 nc -q 0 127.0.0.1 20000

Thanks for help

[miniZ]

@miniZ

Can you try this driver yourself? https://www.nvidia.com/en-us/drivers/results/167421/

@miniZ

Can you try this driver yourself? https://www.nvidia.com/en-us/drivers/results/167421/

Right now, none of the popular miners will work with the newest Nvidia driver version. Latest 457.51 is working. The windows version doesnt matter, from 1909 up to the newest 2H20.

Hi cryptosize, joseph32,

We tried the latest NVIDIA 460.79 driver and also got the error "Cannot read health status! (is libnvidia-ml.so installed?): No such file or directory".

We did look for nvml.dll file and found a few versions in distinct locations, a few were from the recent driver, but most from older driver versions.

We located nvml.dll in C:\Windows\LastGood\system32, which seems to be the most recent functional file, and we copied this file into miniZ folder as a temporary fix.  Perhaps you can also find this file at this location?
edit: Instead of nvml.dll in LastGood, it is best to use the last version of nvml.dll that you can find @ C:\Windows\System32\DriverStore\FileRepository\
          For us it was @  C:\Windows\System32\DriverStore\FileRepository\nvlti.inf_amd64_1b431e1f567ea842
          You can copy the file into miniZ folder as a temporary fix.

We'll give some attention to this, and see if we need to make changes to the miner.

Let us know if this works for you.

Cheers

[miniZ]

Thanks. It works ok ;-)
I didnt know about this curl change. Thanks for info.
Other miners (API) seems to work fine under Ub20.
I had similar problem when migrating from Ub16 to Ub18 - need add "-q" to all nc requests to get work on Ub18

Now I find another method to get API JSON data from your miner (miniz), and seems to work well on all of Ubuntu 16/18/20 ;-)
echo '{"id":"0", "method":"getstat"}' | timeout 5 nc -q 0 127.0.0.1 20000

Thanks for help

Hi tymeksm,

Good that it worked for you.

Thanks for the alternative way to get the API JSON data, it might well be useful to others

Cheers

[cryptosize]

@miniZ

Can you try this driver yourself? https://www.nvidia.com/en-us/drivers/results/167421/

@miniZ

Can you try this driver yourself? https://www.nvidia.com/en-us/drivers/results/167421/

Right now, none of the popular miners will work with the newest Nvidia driver version. Latest 457.51 is working. The windows version doesnt matter, from 1909 up to the newest 2H20.

Hi cryptosize, joseph32,

We tried the latest NVIDIA 460.79 driver and also got the error "Cannot read health status! (is libnvidia-ml.so installed?): No such file or directory".

We did look for nvml.dll file and found a few versions in distinct locations, a few were from the recent driver, but most from older driver versions.

We located nvml.dll in C:\Windows\LastGood\system32, which seems to be the most recent functional file, and we copied this file into miniZ folder as a temporary fix.  Perhaps you can also find this file at this location?
edit: Instead of nvml.dll in LastGood, it is best to use the last version of nvml.dll that you can find @ C:\Windows\System32\DriverStore\FileRepository\
          For us it was @  C:\Windows\System32\DriverStore\FileRepository\nvlti.inf_amd64_1b431e1f567ea842
          You can copy the file into miniZ folder as a temporary fix.

We'll give some attention to this, and see if we need to make changes to the miner.

Let us know if this works for you.

Cheers

Thanks, this fixed it for now.

I guess you plan to support NVAPI in the future for temp/watt measurements? Not everyone will know what to do with nvml.dll.

[bourbonmorning]

* 192,7 major improvements: ~2-11% depending on GPU. Turing GPUs, and 1050 Ti, have the largest improvements.
 * Reduced invalid shares on 192,7.
 * Added 2GB kernel for 192,7 (Linux/Windows7).
 * Added 2GB kernel for 144,5s (beamhash3) (Windows7).

Amazing!!!
Not just BEAM but also ZCL!
You are so cool!
Let's see fee from my 22*1050 soon=)

[miniZ]

Thanks, this fixed it for now.

I guess you plan to support NVAPI in the future for temp/watt measurements? Not everyone will know what to do with nvml.dll.

Hi cryptosize,
yes, we're paying attention to this
Cheers

[miniZ]

* 192,7 major improvements: ~2-11% depending on GPU. Turing GPUs, and 1050 Ti, have the largest improvements.
 * Reduced invalid shares on 192,7.
 * Added 2GB kernel for 192,7 (Linux/Windows7).
 * Added 2GB kernel for 144,5s (beamhash3) (Windows7).

Amazing!!!
Not just BEAM but also ZCL!
You are so cool!
Let's see fee from my 22*1050 soon=)

Hi bourbonmorning,
Thank you
We want to support the largest possible number of GPUs. And we did not forget the old hardware.
Cheers

[UselessGuru]

************ miniZ v1.6w ************
Algo:           EQ[96,5]
Pool#0:         user[*****************************************]
                server[equihash96.eu.mine.zpool.ca] port[2196] ssl[no] pers[auto]
Telemetry:      [http://localhost:4004]
Optimisation:   ocX[0]
Temp. limit:    [90°C]
miniZ<96,5>[02:0:00:5167]: Selecting GPU#0[0] GeForce GTX 1660 SUPER
[ 0d 0h 0m05s] S:  0/0 0>GTX 1660 SUPER ` 100% [45°C/33%] 1012250 I/s 2019438.8(2019438.8)Sol/s  32( 32.2)W clk=1530MHz mclk=7610MHz Sol/W=62756.42 [equihash96.eu.mine.zpool.ca,GLT-Mars]- 96ms
[ 0d 0h 0m10s] S:  0/0 0>GTX 1660 SUPER ` 100% [47°C/33%] 427275 I/s 852413.6(852413.6)Sol/s  51( 50.7)W clk=1530MHz mclk=7610MHz Sol/W=16816.74 [equihash96.eu.mine.zpool.ca,GLT-Mars]- 96ms
[ 0d 0h 0m20s] S:  1/0 0>GTX 1660 SUPER ` 100% [48°C/33%]*114516 I/s 228427.6(228427.6)Sol/s  52( 51.9)W clk=1530MHz mclk=7610MHz Sol/W=4399.64 [equihash96.eu.mine.zpool.ca,GLT-Mars]- 95ms (100.0%) (0.0%)
[ 0d 0h 0m30s] S:  1/0 0>GTX 1660 SUPER ` 100% [48°C/33%] 54863 I/s 109428.4(109428.4)Sol/s  52( 52.4)W clk=1530MHz mclk=7610MHz Sol/W=2086.80 [equihash96.eu.mine.zpool.ca,GLT-Mars]- 95ms (100.0%) (0.0%)

miniZ v1.6w is reporting insane high hashrate when beginning to mine Equihash 96.5.
This leads to incorrect benchmark results.
Other algos - I just tested E1254 - do not show this issue.

As I just noted that this problem still exists in version 1.6x :-(

[miniZ]

************ miniZ v1.6w ************
Algo:           EQ[96,5]
Pool#0:         user[*****************************************]
                server[equihash96.eu.mine.zpool.ca] port[2196] ssl[no] pers[auto]
Telemetry:      [http://localhost:4004]
Optimisation:   ocX[0]
Temp. limit:    [90°C]
miniZ<96,5>[02:0:00:5167]: Selecting GPU#0[0] GeForce GTX 1660 SUPER
[ 0d 0h 0m05s] S:  0/0 0>GTX 1660 SUPER ` 100% [45°C/33%] 1012250 I/s 2019438.8(2019438.8)Sol/s  32( 32.2)W clk=1530MHz mclk=7610MHz Sol/W=62756.42 [equihash96.eu.mine.zpool.ca,GLT-Mars]- 96ms
[ 0d 0h 0m10s] S:  0/0 0>GTX 1660 SUPER ` 100% [47°C/33%] 427275 I/s 852413.6(852413.6)Sol/s  51( 50.7)W clk=1530MHz mclk=7610MHz Sol/W=16816.74 [equihash96.eu.mine.zpool.ca,GLT-Mars]- 96ms
[ 0d 0h 0m20s] S:  1/0 0>GTX 1660 SUPER ` 100% [48°C/33%]*114516 I/s 228427.6(228427.6)Sol/s  52( 51.9)W clk=1530MHz mclk=7610MHz Sol/W=4399.64 [equihash96.eu.mine.zpool.ca,GLT-Mars]- 95ms (100.0%) (0.0%)
[ 0d 0h 0m30s] S:  1/0 0>GTX 1660 SUPER ` 100% [48°C/33%] 54863 I/s 109428.4(109428.4)Sol/s  52( 52.4)W clk=1530MHz mclk=7610MHz Sol/W=2086.80 [equihash96.eu.mine.zpool.ca,GLT-Mars]- 95ms (100.0%) (0.0%)

miniZ v1.6w is reporting insane high hashrate when beginning to mine Equihash 96.5.
This leads to incorrect benchmark results.
Other algos - I just tested E1254 - do not show this issue.

As I just noted that this problem still exists in version 1.6x :-(

Hi UselessGuru,
We are very sorry for this. We'll fix it for the next release!
Thank you for reminder.
Cheers

[guytechie]

Does miniZ exit properly when connection is dropped by the server?  I'm mining in zpool, and in a script, I can write it to loop so if there is a more profitable coin, the server side will drop connection, going to the next line in my script.  The password should include the algos I am profit switching (that's how zpool knows when to drop the connection).

However, right now it seems miniZ does not want to let go...it just stays not mining anything so it won't go to the next line of my script.

I tried different retires and retrydelay settings such as --retries=0 and 1 (just to give it one more try) and --retrydelay=0 and 1 (tried 0, that didn't work, so thought maybe it needed a non-0 value).  Neither 0 retries/seconds nor 1 retry/second works for both retry and retry delay.

Here's a small example:

Code:

:loop
miniZ.exe --retries=1 --retrydelay=1 --templimit 95 --intensity 100 --latency --tempunits C -cd 0 --telemetry 4068 --url xxxx@equihash192.na.mine.zpool.ca:2192 --pass c=BTC,equihash192,equihash144 --algo 192,7 --pers auto --ocX
miniZ.exe --retries=1 --retrydelay=1 --templimit 95 --intensity 100 --latency --tempunits C -cd 0 --telemetry 4068 --url xxxx@equihash144.na.mine.zpool.ca:2144 --pass c=BTC,equihash192,equihash144 --algo 144,5 --pers auto --ocX
goto loop

I'm using the Windows version right now for a proof of concept so I can write a profit switching script for Linux.  In Windows, I've been using NPlusMiner which includes this miner in their package.  But it would be nice to just use a nice clean script to profit-switch and mine.

[miniZ]

Does miniZ exit properly when connection is dropped by the server?  I'm mining in zpool, and in a script, I can write it to loop so if there is a more profitable coin, the server side will drop connection, going to the next line in my script.  The password should include the algos I am profit switching (that's how zpool knows when to drop the connection).

However, right now it seems miniZ does not want to let go...it just stays not mining anything so it won't go to the next line of my script.

I tried different retires and retrydelay settings such as --retries=0 and 1 (just to give it one more try) and --retrydelay=0 and 1 (tried 0, that didn't work, so thought maybe it needed a non-0 value).  Neither 0 retries/seconds nor 1 retry/second works for both retry and retry delay.

Here's a small example:

Code:

:loop
miniZ.exe --retries=1 --retrydelay=1 --templimit 95 --intensity 100 --latency --tempunits C -cd 0 --telemetry 4068 --url xxxx@equihash192.na.mine.zpool.ca:2192 --pass c=BTC,equihash192,equihash144 --algo 192,7 --pers auto --ocX
miniZ.exe --retries=1 --retrydelay=1 --templimit 95 --intensity 100 --latency --tempunits C -cd 0 --telemetry 4068 --url xxxx@equihash144.na.mine.zpool.ca:2144 --pass c=BTC,equihash192,equihash144 --algo 144,5 --pers auto --ocX
goto loop

I'm using the Windows version right now for a proof of concept so I can write a profit switching script for Linux.  In Windows, I've been using NPlusMiner which includes this miner in their package.  But it would be nice to just use a nice clean script to profit-switch and mine.

Hi guytechie,

What do you think it is best? Maybe, an option that can force miniZ exit when the connection drops? Or something else?
We'll add a solution to the next miniZ version (should be out soon!).

Cheers,
miniZ

[guytechie]

Hi guytechie,

What do you think it is best? Maybe, an option that can force miniZ exit when the connection drops? Or something else?
We'll add a solution to the next miniZ version (should be out soon!).

Cheers,
miniZ

I thought that -r 0 -R 0 would cause miniZ to exit when the connection gets dropped.  If not, yes please make it so or a separate option to exit/terminate when connection is dropped.

Please do for both Linux and Windows version.  I have both, and I'm staring to link Linux better, lol.

Thanks!

[tuna2000]

Very impressed with miniZ - with the defaults, it just works.

I'm still getting to grips with the complexities of BTG though, and was trying to see if I could mine without a pool (against a local full node)? Is this possible? (I understand it's not very sensible, but I'm figuring it all out and it helps me understand what the software is doing).

So I tried setting up Bitcoin Gold core with rpc settings (it starts up and doesn't complain), but then if I use my local IP for miniZ, I get 0 Sols/s for a while and then it switches over to the fee server and stays there. No extra debug information about what's going on.

My bitcoin gold core config looks something like this:

Code:

server=1
listen=1
daemon=1
rpcuser=<my-username>
rpcpassword=<my-password>
rpcallowip=192.168.0.0/24
rcpbind=192.168.0.22
rpcport=8333

And then starting up Minz like this:

Code:

G:\Apps\miniz>miniZ.exe --url=<wallet-address>.<my-username>@192.168.0.22:8333 --latency --extra --nocolor --pass=<my-password>
************ miniZ v1.6x ************
Number of CUDA[8.0] devices found: 1
Algo:           EQ[144,5]
Pool#0:         user[<wallet-address>.<my-username>]
                server[192.168.0.22] port[8333] ssl[no] pers[BgoldPoW]
Telemetry:      [http://localhost:20000]
Temp. limit:    [90°C]
miniZ<144,5>[00:0:00:2558]: Selecting GPU#0[0] GeForce GTX 1060 3GB
[ 0d 0h 0m06s] S:  0/0 0>GTX 1060 3GB  100% [63°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  33( 33.3)W clk=1657MHz mclk=3802MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 0m10s] S:  0/0 0>GTX 1060 3GB  100% [63°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  33( 33.3)W clk=1657MHz mclk=3802MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 0m20s] S:  0/0 0>GTX 1060 3GB  100% [64°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  33( 33.4)W clk=1657MHz mclk=3802MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 0m30s] S:  0/0 0>GTX 1060 3GB  100% [63°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  26( 26.2)W clk=151MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 0m40s] S:  0/0 0>GTX 1060 3GB  100% [62°C/ 7%] 0.00 I/s 0.0(0.0)Sol/s  19( 19.5)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 0m50s] S:  0/0 0>GTX 1060 3GB  100% [62°C/ 7%] 0.00 I/s 0.0(0.0)Sol/s  15( 16.5)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 1m00s] S:  0/0 0>GTX 1060 3GB  100% [62°C/ 6%] 0.00 I/s 0.0(0.0)Sol/s  14( 15.0)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 1m10s] S:  0/0 0>GTX 1060 3GB  100% [61°C/ 7%] 0.00 I/s 0.0(0.0)Sol/s  13( 14.0)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 1m20s] S:  0/0 0>GTX 1060 3GB  100% [61°C/ 6%] 0.00 I/s 0.0(0.0)Sol/s  12( 13.5)W clk=164MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 1m30s] S:  0/0 0>GTX 1060 3GB  100% [61°C/ 7%] 0.00 I/s 0.0(0.0)Sol/s  12( 13.1)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 1m40s] S:  0/0 0>GTX 1060 3GB  100% [61°C/ 6%] 0.00 I/s 0.0(0.0)Sol/s  12( 12.8)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 1m50s] S:  0/0 0>GTX 1060 3GB  100% [60°C/ 6%] 0.00 I/s 0.0(0.0)Sol/s  12( 12.6)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 2m00s] S:  0/0 0>GTX 1060 3GB  100% [60°C/ 6%] 0.00 I/s 0.0(0.0)Sol/s  12( 12.5)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 2m10s] S:  0/0 0>GTX 1060 3GB  100% [61°C/ 6%] 0.00 I/s 0.0(0.0)Sol/s  16( 13.9)W clk=670MHz mclk=810MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 2m20s] S:  0/0 0>GTX 1060 3GB  100% [60°C/ 6%] 0.00 I/s 0.0(0.0)Sol/s  14( 13.5)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 2m30s] S:  0/0 0>GTX 1060 3GB  100% [60°C/ 7%] 0.00 I/s 0.0(0.0)Sol/s  13( 13.3)W clk=164MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 2m40s] S:  0/0 0>GTX 1060 3GB  100% [60°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  12( 13.1)W clk=177MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 2m50s] S:  0/0 0>GTX 1060 3GB  100% [60°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  12( 12.9)W clk=177MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 3m00s] S:  0/0 0>GTX 1060 3GB  100% [59°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  12( 12.7)W clk=177MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 3m10s] S:  0/0 0>GTX 1060 3GB  100% [59°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  12( 12.6)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 3m20s] S:  0/0 0>GTX 1060 3GB  100% [59°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  11( 12.5)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 3m30s] S:  0/0 0>GTX 1060 3GB  100% [59°C/ 0%] 0.00 I/s 0.0(0.0)Sol/s  11( 12.4)W clk=139MHz mclk=405MHz Sol/W=0.00 [192.168.0.22]- 0ms (100.0%) (0.0%)
[ 0d 0h 3m40s] S:  0/0 0>GTX 1060 3GB  100% [58°C/ 0%] 0.41 I/s 1.3(1.3)Sol/s  11( 12.3)W clk=139MHz mclk=405MHz Sol/W=0.11 [fee.server]- 28ms (100.0%) (0.0%)
[ 0d 0h 3m50s] S:  0/0 0>GTX 1060 3GB  100% [68°C/ 0%] 1.92 I/s 4.6(4.2)Sol/s  62( 21.1)W clk=1797MHz mclk=3802MHz Sol/W=0.20 [fee.server]- 28ms (95.6%) (4.4%)
[ 0d 0h 4m00s] S:  0/0 0>GTX 1060 3GB  100% [72°C/25%] 3.31 I/s 7.5(6.6)Sol/s  90( 29.1)W clk=1771MHz mclk=3802MHz Sol/W=0.23 [fee.server]- 28ms (91.6%) (8.4%)
[ 0d 0h 4m10s] S:  0/0 0>GTX 1060 3GB  100% [75°C/34%] 4.55 I/s 9.9(8.6)Sol/s  98( 35.2)W clk=1759MHz mclk=3802MHz Sol/W=0.25 [fee.server]- 29ms (87.6%) (12.4%)
[ 0d 0h 4m20s] S:  0/0 0>GTX 1060 3GB  100% [77°C/41%] 5.70 I/s 12.4(10.7)Sol/s 103( 40.9)W clk=1759MHz mclk=3802MHz Sol/W=0.26 [fee.server]- 29ms (84.2%) (15.8%)
[ 0d 0h 4m30s] S:  0/0 0>GTX 1060 3GB  100% [78°C/46%] 7.72 I/s 16.4(13.9)Sol/s 110( 46.5)W clk=1759MHz mclk=3802MHz Sol/W=0.30 [fee.server]- 29ms (81.3%) (18.7%)
[ 0d 0h 4m40s] S:  0/0 0>GTX 1060 3GB  100% [79°C/50%] 8.62 I/s 18.7(15.7)Sol/s 112( 51.3)W clk=1746MHz mclk=3802MHz Sol/W=0.31 [fee.server]- 29ms (78.1%) (21.9%)
[ 0d 0h 4m50s] S:  0/0 0>GTX 1060 3GB  100% [80°C/53%] 9.44 I/s 20.0(16.8)Sol/s 117( 56.1)W clk=1759MHz mclk=3802MHz Sol/W=0.30 [fee.server]- 29ms (75.7%) (24.3%)
[ 0d 0h 5m00s] S:  0/0 0>GTX 1060 3GB  100% [81°C/55%] 10.19 I/s 21.5(18.0)Sol/s 117( 60.1)W clk=1746MHz mclk=3802MHz Sol/W=0.30 [fee.server]- 29ms (73.2%) (26.8%)
[ 0d 0h 5m10s] S:  0/0 0>GTX 1060 3GB  100% [81°C/57%] 10.87 I/s 22.6(18.9)Sol/s 116( 63.6)W clk=1746MHz mclk=3802MHz Sol/W=0.30 [fee.server]- 29ms (70.8%) (29.2%)
[ 0d 0h 5m20s] S:  0/0 0>GTX 1060 3GB  100% [82°C/58%] 12.06 I/s 25.0(20.7)Sol/s 116( 66.8)W clk=1771MHz mclk=3802MHz Sol/W=0.31 [fee.server]- 29ms (68.6%) (31.4%)
[ 0d 0h 5m30s] S:  0/0 0>GTX 1060 3GB  100% [82°C/59%] 12.58 I/s 26.0(21.6)Sol/s 112( 69.2)W clk=1721MHz mclk=3802MHz Sol/W=0.31 [fee.server]- 29ms (66.5%) (33.5%)
[ 0d 0h 5m40s] S:  0/0 0>GTX 1060 3GB  100% [82°C/59%] 12.81 I/s 26.4(22.0)Sol/s  98( 69.7)W clk=1733MHz mclk=3802MHz Sol/W=0.32 [fee.server]- 29ms (64.5%) (35.5%)
[ 0d 0h 5m50s] S:  0/0 0>GTX 1060 3GB  100% [82°C/59%] 13.23 I/s 27.3(22.7)Sol/s 111( 72.8)W clk=1759MHz mclk=3802MHz Sol/W=0.31 [fee.server]- 29ms (62.6%) (37.4%)
[ 0d 0h 6m00s] S:  0/0 0>GTX 1060 3GB  100% [82°C/60%] 13.65 I/s 27.9(23.3)Sol/s 117( 75.5)W clk=1721MHz mclk=3802MHz Sol/W=0.31 [fee.server]- 29ms (60.9%) (39.1%)

Where usename and password are just random strings, and wallet-address is a payment address generated in my wallet.

I'm sure I'm driving it wrong, but is this sort of setup possible?

[miniZ]

Very impressed with miniZ - with the defaults, it just works.

I'm still getting to grips with the complexities of BTG though, and was trying to see if I could mine without a pool (against a local full node)? Is this possible? (I understand it's not very sensible, but I'm figuring it all out and it helps me understand what the software is doing).

So I tried setting up Bitcoin Gold core with rpc settings (it starts up and doesn't complain), but then if I use my local IP for miniZ, I get 0 Sols/s for a while and then it switches over to the fee server and stays there. No extra debug information about what's going on.


Where usename and password are just random strings, and wallet-address is a payment address generated in my wallet.

I'm sure I'm driving it wrong, but is this sort of setup possible?

Hi tuna2000,

Thank you for your message.
Sorry for taking a bit longer to reply.

It should be possible to mine without a pool (against a local full node).

We did not fully investigate this, miniZ is optimised to mine with a pool.

Maybe the best would be to post the question directly to the Bitgoin Gold forum.

Hope you can manage to make it work, however keep in mind that unless you have hudge hash power rig it can take a really long time to mine a block.

Cheers,
miniZ

[platinum4]

@miniZ could you please investigate wrong power draw usage on NVML?  Driver is 461.09 and miniZ seems to read 2.0x the power draw:

[miniZ]

@miniZ could you please investigate wrong power draw usage on NVML?  Driver is 461.09 and miniZ seems to read 2.0x the power draw:

Hi platinum4,

This seems to be an issue with the driver that stopped reporting the power draw for your GPU in nvml, so miniZ is showing the maximum value.

We'll investigate further and see if we can do something about it.

Thank you for the feedback!
Cheers,
miniZ