miniZ v2.0a Equihash 144,5 125,4 210,9 150,5 192,7 BeamHash3 ProgPoW Ethash CFX - page 16.

guytechie

hero member

Activity: 677

Merit: 500

Quote from: miniZ on January 23, 2021, 09:14:47 PM

Quote from: guytechie on January 23, 2021, 03:30:53 PM

Hi miniZ. Have you implemented the termination on disconnect feature yet? If so, when will the next version coming out with that implemented?

Hi guytechie,
We already implemented the fix. Sorry for taking longer than expected.
Because we're making a few changes, we need to test it well. We are currently testing the miner and it will be out this week.
Cheers,
miniZ

Thanks for the update. So how does it work? Do we put -r 0 -R 0, or is there a different switch to invoke this feature?

miniZ

member

Activity: 679

Merit: 17

Quote from: guytechie on January 23, 2021, 03:30:53 PM

Hi miniZ. Have you implemented the termination on disconnect feature yet? If so, when will the next version coming out with that implemented?

Hi guytechie,
We already implemented the fix. Sorry for taking longer than expected.
Because we're making a few changes, we need to test it well. We are currently testing the miner and it will be out this week.
Cheers,
miniZ

guytechie

hero member

Activity: 677

Merit: 500

Hi miniZ. Have you implemented the termination on disconnect feature yet? If so, when will the next version coming out with that implemented?

miniZ

member

Activity: 679

Merit: 17

Quote from: platinum4 on January 21, 2021, 04:41:38 AM

@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

platinum4

sr. member

Activity: 547

Merit: 250

@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

member

Activity: 679

Merit: 17

Quote from: tuna2000 on January 17, 2021, 10:18:21 AM

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

tuna2000

newbie

Activity: 1

Merit: 0

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=
rpcpassword=
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=.@192.168.0.22:8333 --latency --extra --nocolor --pass=
************ miniZ v1.6x ************
Number of CUDA[8.0] devices found: 1
Algo:           EQ[144,5]
Pool#0:         user[.]
                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?

guytechie

hero member

Activity: 677

Merit: 500

Quote from: miniZ on December 31, 2020, 01:33:07 PM

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!

miniZ

member

Activity: 679

Merit: 17

Quote from: guytechie on December 30, 2020, 05:41:18 PM

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 [email protected]: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 [email protected]: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

hero member

Activity: 677

Merit: 500

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 [email protected]: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 [email protected]: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

member

Activity: 679

Merit: 17

Quote from: UselessGuru on December 15, 2020, 05:08:29 AM

Quote from: UselessGuru on October 17, 2020, 11:32:10 AM

************ 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

UselessGuru

jr. member

Activity: 200

Merit: 3

Quote from: UselessGuru on October 17, 2020, 11:32:10 AM

************ 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

member

Activity: 679

Merit: 17

Quote from: bourbonmorning on December 12, 2020, 05:16:22 PM

Quote from: miniZ on October 29, 2020, 07:52:08 PM

* 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

miniZ

member

Activity: 679

Merit: 17

Quote from: cryptosize on December 10, 2020, 07:51:05 PM

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

bourbonmorning

newbie

Activity: 27

Merit: 0

Quote from: miniZ on October 29, 2020, 07:52:08 PM

* 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=)

cryptosize

sr. member

Activity: 1624

Merit: 294

Quote from: miniZ on December 10, 2020, 06:15:52 PM

Quote from: cryptosize on December 09, 2020, 08:30:11 PM

@miniZ

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

Quote from: joseph32 on December 10, 2020, 03:49:44 AM

Quote from: cryptosize on December 09, 2020, 08:30:11 PM

@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.

miniZ

member

Activity: 679

Merit: 17

Quote from: tymeksm on December 10, 2020, 03:50:36 AM

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

miniZ

member

Activity: 679

Merit: 17

Quote from: cryptosize on December 09, 2020, 08:30:11 PM

@miniZ

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

Quote from: joseph32 on December 10, 2020, 03:49:44 AM

Quote from: cryptosize on December 09, 2020, 08:30:11 PM

@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

tymeksm

member

Activity: 634

Merit: 12

Quote from: miniZ on December 09, 2020, 03:01:17 PM

Quote from: tymeksm on December 09, 2020, 10:14:12 AM

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

joseph32

member

Activity: 412

Merit: 21

Quote from: cryptosize on December 09, 2020, 08:30:11 PM

@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.

Topic: miniZ v2.0a Equihash 144,5 125,4 210,9 150,5 192,7 BeamHash3 ProgPoW Ethash CFX - page 16. (Read 59063 times)