hi any have hashrate for Equihash 192,7 (Equihash Heavy):
FOR RTX CARDS 3080 & 3090 really important for me any1 cheers
Topic: miniZ v2.0a Equihash 144,5 125,4 210,9 150,5 192,7 BeamHash3 ProgPoW Ethash CFX - page 17. (Read 60004 times)
February 14, 2021, 01:55:20 AM
February 11, 2021, 04:33:12 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
Hi. Any updates?
Sorry for such a late response.
We ended up making major changes.
Currently, we are finalising testing. We expect to release a new version in no more than two days.
Thank you for your patience.
Cheers,
miniZ
February 11, 2021, 01:04:30 AM
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
Hi. Any updates?
January 28, 2021, 06:17:38 PM
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?
We added an option --quit-disconnect.
Is this OK for you?
Cheers,
miniZ
That sounds perfect! Can't wait for the next release! Thanks!
Any idea when that is?
January 26, 2021, 06:47:34 PM
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?
We added an option --quit-disconnect.
Is this OK for you?
Cheers,
miniZ
January 24, 2021, 11:25:09 AM
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?
January 23, 2021, 08:14:47 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
January 23, 2021, 02: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?
January 22, 2021, 06:31:28 PM
@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
January 21, 2021, 03: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:
January 20, 2021, 03:11:06 PM
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?
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
January 17, 2021, 09: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.
My bitcoin gold core config looks something like this:
And then starting up Minz like this:
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?
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?
December 31, 2020, 12:41:45 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!
December 31, 2020, 12:33:07 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:
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,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.
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
December 30, 2020, 04: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:
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.
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.
December 16, 2020, 12:15:55 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 :-(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.
Hi UselessGuru,
We are very sorry for this. We'll fix it for the next release!
Thank you for reminder.
Cheers
December 15, 2020, 04:08:29 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 :-( 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.
December 13, 2020, 05:37:51 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!!!* Reduced invalid shares on 192,7.
* Added 2GB kernel for 192,7 (Linux/Windows7).
* Added 2GB kernel for 144,5s (beamhash3) (Windows7).
Not just BEAM but also ZCL!
You are so cool!
Let's see fee from my 22*1050 soon=)
Thank you
We want to support the largest possible number of GPUs. And we did not forget the old hardware.
Cheers
December 13, 2020, 05:35:20 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.
yes, we're paying attention to this
Cheers
December 12, 2020, 04:16:22 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!!!* Reduced invalid shares on 192,7.
* Added 2GB kernel for 192,7 (Linux/Windows7).
* Added 2GB kernel for 144,5s (beamhash3) (Windows7).
Not just BEAM but also ZCL!
You are so cool!
Let's see fee from my 22*1050 soon=)
Jump to: