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

[miniZ]

Hi everyone,

A new version miniZ v1.5u2 is out with a fix for an issue that on ZEL mining was not submitting shares on some pools.

We also had the opportunity to adjust kernels for the 1070. It should start with the best kernel now, on stock settings.

We will keep working to make miniZ better.

Download miniZ v1.5u2 here.

Changelog:

* Fixed bug that on ZEL mining was not submitting shares on some pools ex: 2miners.
* Adjusted default kernels for GTX1070, on stock settings, for all algorithms.

Let us know how it goes!

Thank you all for your feedback!

[Kringel]

With 1070s, the new version is painfully slow on beamv2 (~1.7 times slower than the previous one) and all found shares are rejected by the Nicehash pool.

must be the pool you choose to mine on giving you the problems, i'm mining Beam directly and the new version is pretty much no different to the previous.

Hi Kringel, rgsnedds,

Thank you for your messages.

We haven't change anything significantly, on Beam.

Kringel, you say that with t3 it works fine and with the new version you have rejected shares and performance drops, with the same command line?
Could you maybe paste here the start of your log?

We are investigating this.

Cheers

Yes, the command line is the same, I upgraded-downgraded miniZ one more time and can confirm the problem with the new version(s).
The u2 didn't change much, it just stopped saying that OC2 kernel is not available for 1070 (the switch is there just in case you implement it sometime; I tried to remove it, nothing changes).

Start of the output (the test rig is a miniPC with two 1070s, one of them is limited to 70% TDP):

Code:

************ miniZ v1.5u2 ************
Algo:           EQ[150,5]
Pool#0:         user[...] server[beamv2.eu.nicehash.com] port[3378] ssl[no] pers[auto]
Pool#1:         user[...] server[beamv2.usa.nicehash.com] port[3378] ssl[no] pers[auto]
Pool#2:         user[...] server[beamv2.hk.nicehash.com] port[3378] ssl[no] pers[auto]
Pool#3:         user[...] server[beamv2.jp.nicehash.com] port[3378] ssl[no] pers[auto]
Pool#4:         user[...] server[beamv2.in.nicehash.com] port[3378] ssl[no] pers[auto]
Pool#5:         user[...] server[beamv2.br.nicehash.com] port[3378] ssl[no] pers[auto]
Pool#6:         user[...] server[beamv2.eu.nicehash.com] port[3378] ssl[no] pers[auto]
Telemetry:      [http://localhost:4002]
Optimisation:   oc1[0] oc2[1]
Temp. limit:    [90°C]
miniZ<150,5>[8:0:00:6787]: Selecting GPU#0[0] GeForce GTX 1070
miniZ<150,5>[1:0:00:6787]: Selecting GPU#1[1] GeForce GTX 1070
[ 0d 0h 0m10s] 38(37.8)Sol/s 253(253.2)W
 0>GTX 1070     ` 100% [60°C/38%]  9.66 I/s 17.8(17.8)Sol/s 106(105.8)W clk=1316MHz mclk=4252MHz Sol/W=0.17
 1>GTX 1070     ` 100% [60°C/38%] 10.74 I/s 20.0(20.0)Sol/s 147(147.4)W clk=1670MHz mclk=4252MHz Sol/W=0.14
[ 0d 0h 0m20s] 41(40.8)Sol/s 255(254.6)W
 0>GTX 1070     `0.00% [61°C/42%]*10.05 I/s 19.4(19.4)Sol/s 106(105.9)W clk=1215MHz mclk=4252MHz Sol/W=0.18
 1>GTX 1070     ` 100% [61°C/42%] 11.24 I/s 20.7(20.7)Sol/s 149(148.6)W clk=1670MHz mclk=4252MHz Sol/W=0.14
[ 0d 0h 0m30s] 42(42.3)Sol/s 248(247.7)W
 0>GTX 1070     `0.00% [62°C/42%] 10.12 I/s 20.4(20.4)Sol/s 103(102.9)W clk=1290MHz mclk=4252MHz Sol/W=0.20
 1>GTX 1070     ` 100% [61°C/42%] 11.35 I/s 21.7(21.7)Sol/s 145(144.9)W clk=1657MHz mclk=4252MHz Sol/W=0.15
[ 0d 0h 0m40s] 41(41.4)Sol/s 251(250.6)W
 0>GTX 1070     `0.00% [62°C/44%] 10.14 I/s 19.9(19.9)Sol/s 105(104.6)W clk=1303MHz mclk=4252MHz Sol/W=0.19
 1>GTX 1070     `0.00% [62°C/44%]*11.39 I/s 21.4(21.4)Sol/s 146(146.1)W clk=1670MHz mclk=4252MHz Sol/W=0.15
[ 0d 0h 0m50s] 42(41.9)Sol/s 250(250.0)W
 0>GTX 1070     `0.00% [63°C/46%] 10.12 I/s 20.0(20.0)Sol/s 105(104.9)W clk=1177MHz mclk=4252MHz Sol/W=0.19
 1>GTX 1070     `0.00% [63°C/46%] 11.38 I/s 22.0(22.0)Sol/s 145(145.1)W clk=1670MHz mclk=4252MHz Sol/W=0.15
[ 0d 0h 1m00s] 41(41.2)Sol/s 250(249.7)W
 0>GTX 1070     `0.00% [63°C/46%] 10.15 I/s 19.5(19.5)Sol/s 103(103.6)W clk=1303MHz mclk=4252MHz Sol/W=0.19
 1>GTX 1070     `0.00% [64°C/46%] 11.38 I/s 21.8(21.8)Sol/s 147(146.1)W clk=1670MHz mclk=4252MHz Sol/W=0.15

A healthy output with t3 and the same settings:

Code:

************ miniZ v1.5t3 ************
Algo:           EQ[150,5]
Pool#0:         user[...] server[beamv2.eu.nicehash.com] port[3378] ssl[no] pers[Beam-PoW]
Pool#1:         user[...] server[beamv2.usa.nicehash.com] port[3378] ssl[no] pers[Beam-PoW]
Pool#2:         user[...] server[beamv2.hk.nicehash.com] port[3378] ssl[no] pers[Beam-PoW]
Pool#3:         user[...] server[beamv2.jp.nicehash.com] port[3378] ssl[no] pers[Beam-PoW]
Pool#4:         user[...] server[beamv2.in.nicehash.com] port[3378] ssl[no] pers[Beam-PoW]
miniZ<150,5,3>[09:0:00:6788]: Selecting GPU#0[0] GeForce GTX 1070
Pool#5:         user[...] server[beamv2.br.nicehash.com] port[3378] ssl[no] pers[Beam-PoW]
Pool#6:         user[...] server[beamv2.eu.nicehash.com] port[3378] ssl[no] pers[Beam-PoW]
Telemetry:      [http://localhost:4003]
Optimisation:   oc1[0] oc2[1]
Temp. limit:    [90°C]
[WARNING] GPU[1]: GeForce GTX 1070 does not have oc2 for this algo.
miniZ<150,5,3>[04:0:00:6788]: Selecting GPU#1[1] GeForce GTX 1070
[ 0d 0h 0m10s] 64(63.7)Sol/s 257(257.3)W
 0>GTX 1070     ` 100% [61°C/41%] 15.67 I/s 27.4(27.4)Sol/s 105(104.8)W clk=1493MHz mclk=4252MHz Sol/W=0.26
 1>GTX 1070     ` 100% [60°C/39%] 17.75 I/s 33.7(33.7)Sol/s 153(152.5)W clk=1733MHz mclk=4252MHz Sol/W=0.22
[ 0d 0h 0m20s] 66(65.9)Sol/s 254(254.1)W
 0>GTX 1070     ` 100% [61°C/42%]*16.32 I/s 30.4(30.4)Sol/s 105(105.1)W clk=1480MHz mclk=4252MHz Sol/W=0.29
 1>GTX 1070     ` 100% [61°C/41%]*18.50 I/s 34.5(34.5)Sol/s 149(149.0)W clk=1746MHz mclk=4252MHz Sol/W=0.23
[ 0d 0h 0m30s] 70(69.8)Sol/s 257(256.6)W
 0>GTX 1070     ` 100% [62°C/44%] 16.44 I/s 33.1(33.1)Sol/s 106(106.4)W clk=1518MHz mclk=4252MHz Sol/W=0.31
 1>GTX 1070     ` 100% [62°C/42%] 18.64 I/s 36.2(36.2)Sol/s 150(150.2)W clk=1721MHz mclk=4252MHz Sol/W=0.24
[ 0d 0h 0m40s] 70(70.5)Sol/s 253(253.2)W
 0>GTX 1070     ` 100% [63°C/46%] 16.48 I/s 33.8(33.8)Sol/s 106(106.0)W clk=1493MHz mclk=4252MHz Sol/W=0.32
 1>GTX 1070     ` 100% [63°C/44%] 18.69 I/s 36.1(36.1)Sol/s 147(147.2)W clk=1721MHz mclk=4252MHz Sol/W=0.25
[ 0d 0h 0m50s] 70(69.9)Sol/s 251(251.9)W
 0>GTX 1070     ` 100% [63°C/46%] 16.51 I/s 33.7(33.7)Sol/s 107(106.4)W clk=1493MHz mclk=4252MHz Sol/W=0.32
 1>GTX 1070     ` 100% [63°C/46%] 18.70 I/s 36.4(36.4)Sol/s 145(145.5)W clk=1721MHz mclk=4252MHz Sol/W=0.25
[ 0d 0h 1m00s] 70(69.9)Sol/s 251(251.9)W
 0>GTX 1070     ` 100% [64°C/48%] 16.51 I/s 33.0(33.0)Sol/s 107(106.5)W clk=1493MHz mclk=4252MHz Sol/W=0.31
 1>GTX 1070     ` 100% [64°C/48%] 18.69 I/s 36.6(36.6)Sol/s 145(145.4)W clk=1708MHz mclk=4252MHz Sol/W=0.25

The driver version is 442.92.

[miniZ]

Yes, the command line is the same, I upgraded-downgraded miniZ one more time and can confirm the problem with the new version(s).
The u2 didn't change much, it just stopped saying that OC2 kernel is not available for 1070 (the switch is there just in case you implement it sometime; I tried to remove it, nothing changes).

Start of the output (the test rig is a miniPC with two 1070s, one of them is limited to 70% TDP):

Code:

************ miniZ v1.5u2 ************
Algo:           EQ[150,5]
Pool#0:         user[...] server[beamv2.eu.nicehash.com] port[3378] ssl[no] pers[auto]

Hi Kringel,
we think we understand the problem.

Are you specifying the algo in the command line?  --par=150,5 ?
It is entering the wrong algo in the new version.

In t3 version it was working because we used to ignore the par argument while mining Beam (because of the last fork, a verification that was never removed). We have been preparing for the next algo change and we took it out.

You need to write --par=150,5,3 or do not use par at all, miniZ will enter the right algo if it is not specified.

Hope this helps.
Cheers

[Kringel]

Hi Kringel,
we think we understand the problem.

Are you specifying the algo in the command line?  --par=150,5 ?
It is entering the wrong algo in the new version.

In t3 version it was working because we used to ignore the par argument while mining Beam (because of the last fork, a verification that was never removed). We have been preparing for the next algo change and we took it out.

You need to write --par=150,5,3 or do not use par at all, miniZ will enter the right algo if it is not specified.

Hope this helps.
Cheers

I've checked this, the Nicehash client fork indeed specifies --par=150,5 in the command line. All I could do for now is adding --par=150,5,3 in addition to --par=150,5 (before it, actually); that didn't help. I'll contact the author of the program.

[impynick]

[TRACE  ] GPU[0]: switch mode 8 -> mode 9, speed=20.41+0.03% max:20.413[08]
[FATAL  ] GPU[0]: CUDA error 77 'an illegal memory access was encountered' in line 1021

Only happens with miniz. Same settings work with Gminer. I even dropped mem OC from 500 to 400 and still getting this error. Miner shuts down.

I am using ocX setting. How can i get it to assign "mode 8" to this gpu? Seems to crash when switching to "mode 9"

I want to use MiniZ but its not stable atm.  On 150,5 (grimm/Defis)

[miniZ]

Hi Kringel,
we think we understand the problem.

Are you specifying the algo in the command line?  --par=150,5 ?
It is entering the wrong algo in the new version.

In t3 version it was working because we used to ignore the par argument while mining Beam (because of the last fork, a verification that was never removed). We have been preparing for the next algo change and we took it out.

You need to write --par=150,5,3 or do not use par at all, miniZ will enter the right algo if it is not specified.

Hope this helps.
Cheers

I've checked this, the Nicehash client fork indeed specifies --par=150,5 in the command line. All I could do for now is adding --par=150,5,3 in addition to --par=150,5 (before it, actually); that didn't help. I'll contact the author of the program.

Hi Kringel,
Thank you for letting us know.

Writing --par=150,5,3 after --par=150,5 would work... The last one overrides the previous one.

Can you try this? : Add -p just before --par=150,5.  The command line would then end with -p --par=150,5.
This will set the whole string --par=150,5 to the password.

Maybe you can manage with this workaround?

Cheers

[miniZ]

[TRACE  ] GPU[0]: switch mode 8 -> mode 9, speed=20.41+0.03% max:20.413[08]
[FATAL  ] GPU[0]: CUDA error 77 'an illegal memory access was encountered' in line 1021

Only happens with miniz. Same settings work with Gminer. I even dropped mem OC from 500 to 400 and still getting this error. Miner shuts down.

I am using ocX setting. How can i get it to assign "mode 8" to this gpu? Seems to crash when switching to "mode 9"

I want to use MiniZ but its not stable atm.  On 150,5 (grimm/Defis)

Hi impynick,

Maybe mode 8 is stable with your OCs. You can run mode 8 on a specific GPU by adding to your command line --modeN=8, where N=PCI_ID (number appearing after # on log start, GPU#N). To apply it to all GPUs is just --mode=8.

However, you can make sure that it is not OC-related by running a mode in stock settings.

Could you let us know which GPU(s) are you using?

Let us know if problem persists.
Thanks!
Cheers

[Kringel]

I've checked this, the Nicehash client fork indeed specifies --par=150,5 in the command line. All I could do for now is adding --par=150,5,3 in addition to --par=150,5 (before it, actually); that didn't help. I'll contact the author of the program.

Hi Kringel,
Thank you for letting us know.

Writing --par=150,5,3 after --par=150,5 would work... The last one overrides the previous one.

Can you try this? : Add -p just before --par=150,5.  The command line would then end with -p --par=150,5.
This will set the whole string --par=150,5 to the password.

Maybe you can manage with this workaround?

Cheers

Thanks for the quick responses and insight on the source of the problem.

Unfortunately all custom parameters in the Nicehash fork always appear at the start of the final parameter string, and --par is somewhere in the middle of the default command line, so with additional -p miniZ just stops working. Have to wait for a fix, usually they arrive relatively fast.

UPD: actually, I already see the fix on the Github, will try it tomorrow.

[impynick]

I've checked this, the Nicehash client fork indeed specifies --par=150,5 in the command line. All I could do for now is adding --par=150,5,3 in addition to --par=150,5 (before it, actually); that didn't help. I'll contact the author of the program.

Hi Kringel,
Thank you for letting us know.

Writing --par=150,5,3 after --par=150,5 would work... The last one overrides the previous one.

Can you try this? : Add -p just before --par=150,5.  The command line would then end with -p --par=150,5.
This will set the whole string --par=150,5 to the password.

Maybe you can manage with this workaround?

Cheers

Thanks for the quick responses and insight on the source of the problem.

Unfortunately all custom parameters in the Nicehash fork always appear at the start of the final parameter string, and --par is somewhere in the middle of the default command line, so with additional -p miniZ just stops working. Have to wait for a fix, usually they arrive relatively fast.

UPD: actually, I already see the fix on the Github, will try it tomorrow.

:loop
.\miniZ.exe --url=ssl://3d8504893c964b667d87e7f37b90ee2adfec2d5c52d5a1b571bc6a5261b47fb421c@censord.com:3333 -p x --par=150,5 --pers=GrimmPOW --show-shares --shares-detail --latency --extra --all-shares --log --mode0=8
timeout /t 5
goto loop

Miner doesnt start

It will start when I put it as "--mode=8". Trying to assign modes to GPUs doesnt work. Also there's literally 0 explanation in the readme or your website on the different modes. I only found this out by running --ocX. It would be nice if you went into detail about the modes and how to use them properly.

[miniZ]

Thanks for the quick responses and insight on the source of the problem.

Unfortunately all custom parameters in the Nicehash fork always appear at the start of the final parameter string, and --par is somewhere in the middle of the default command line, so with additional -p miniZ just stops working. Have to wait for a fix, usually they arrive relatively fast.

UPD: actually, I already see the fix on the Github, will try it tomorrow.

Hi Kringel,
That is great news! Thank you for contacting Nicehash.
Also, thanks to Nicehash for providing a fix this fast.
Hope all goes well now.
Cheers

[miniZ]

It will start when I put it as "--mode=8". Trying to assign modes to GPUs doesnt work. Also there's literally 0 explanation in the readme or your website on the different modes. I only found this out by running --ocX. It would be nice if you went into detail about the modes and how to use them properly.

Hi impynick,
--mode has been an experimental setting and we often make some modifications.
Yet, you have a point, we will introduce some information about it in the website. 

Regarding the error, please try --mode0 8 (without the  '='). Sorry about this. Normally miniZ options work both ways (with and without '='). Could you let us know if it works this way? Or if there is something else going on?

Thanks a lot for the feedback!
Cheers

[Kringel]

UPD: actually, I already see the fix on the Github, will try it tomorrow.

...
That is great news! Thank you for contacting Nicehash.
Also, thanks to Nicehash for providing a fix this fast.

It's not the official Nicehash client, it's a [kind of better] fork maintained by an independent developer

Hope all goes well now.

Not exactly. Now it technically works, but I'm completely lost with the new oc/mode settings. Why --ocX alternates mode instead of OC kernels? Shouldn't there be a --modeX option? Does specifying oc1/oc2 still makes sense? Why new default settings for 1070 are far from optimal (at least for ZHash)? How much time a complete optimization cycle takes (there is no clear indication of what it is doing at the moment – optimizes or not)?

It's a total undocumented mess now

EDIT: Also, why the syntax (address/value position) for --modeN is basically the opposite of that for --ocN? Why --ocX disables selection of oc1/oc2 kernels? Why some modes are skipped during optimization? Finally, what's the "mode" here?

[impynick]

It will start when I put it as "--mode=8". Trying to assign modes to GPUs doesnt work. Also there's literally 0 explanation in the readme or your website on the different modes. I only found this out by running --ocX. It would be nice if you went into detail about the modes and how to use them properly.

Hi impynick,
--mode has been an experimental setting and we often make some modifications.
Yet, you have a point, we will introduce some information about it in the website. 

Regarding the error, please try --mode0 8 (without the  '='). Sorry about this. Normally miniZ options work both ways (with and without '='). Could you let us know if it works this way? Or if there is something else going on?

Thanks a lot for the feedback!
Cheers

Sure i will give it a shot. Dont mean to come across in a rude way. Thank you guys for your work on the miner

[somaton]

is it me or it is not possible to specify two pools with --server command? I have two servers in one .bat, but miniz will see only the second one, the first one is ignored.

miniz.exe --par=192,7 --pers=auto --server pool1 --port 2144 --user xxx --pass x --server pool2 --port 2192 --user xxx --pass x

************ miniZ v1.5u2 ************
Number of CUDA[10.0] devices found: 2
Algo:           EQ[192,7]
Pool#0:         user[xxx]
                server[pool2] port[2192] ssl[no] pers[auto]
Temp. limit:    [90°C]
miniZ<192,7>[8:0:00:10953]: Selecting GPU#0[0] GeForce GTX 1080 Ti
miniZ<192,7>[8:0:00:10953]: Selecting GPU#1[1] GeForce GTX 1080 Ti

[Ziv1]

Any appeal to the GPUZ causes the miner to crash.
 Confuses memory used-3067mb
(in version 1.5t) 2692mb respectively.

[somaton]

tried two servers in different way:

miniz.exe --par=192,7 --pers=auto --url=user@pool1:2144 --pass c=BTC,mc=SAFE/YEC/ARW --url=user@pool2:2192 --pass c=BTC,zap=ZER/SAFE/VDL,d=8

this way miniz sees two pools, but...password for second pool is used for pool1 too...I did not find any examples with password from your miniz.ch.

[miniZ]

Thanks for the quick responses and insight on the source of the problem.

Unfortunately all custom parameters in the Nicehash fork always appear at the start of the final parameter string, and --par is somewhere in the middle of the default command line, so with additional -p miniZ just stops working. Have to wait for a fix, usually they arrive relatively fast.

UPD: actually, I already see the fix on the Github, will try it tomorrow.

Hi Kringel, impynick, and everyone,

Some time ago we realized we could try and add some flexibility to miniZ. We created --oc1 and --oc2 to set a specific kernel (we called it mode in the messages) for the GPUs, other than the default. These refer to kernels we noticed that performed better than the default, for some overclock settings, and only for some GPUs. This is why not all GPUs have oc1 or oc2. Sometimes the default (optimised for stock settings) was the best we found.

--mode is just a way to select a specific mode/kernel for miniZ to run in your GPU. We were using this mostly to test with the GPU models we did not have access to, because we could tell someone to try a specific kernel. So this was mostly an experimental and debugging option.

More recently we managed to make it better with --ocX. --ocX will run a few available miniZ kernels and choose the one that performs best, for your GPU, and for the overclocks you apply to your GPU.

Do not use oc1/oc2/ocX (or --mode) at the same time on the same GPU. This could cause confusion in understanding miniZ behavior. One of the options will prevail though, usually the last one appearing in the command line.

We managed to have access to a 1070 this week so we will optimise the kernels for that card. Meanwhile, you can use ocX to find what is the best kernel mode for your card. If you care to share your findings we can than compare with ours.

The duration can vary, for each mode miniZ checks if there is some stability (temperature, performance...). After testing all available modes for that GPU it will stop switching, then prints a message indicating that tune is finished and the best mode that was found (and sols for that mode). Then it continues mining with the best mode it had found before.

 We hope these will also help to clear some of the confusion. We added some FAQs explaining this too. There you'll be able to find some usage examples.

Thank you for sharing your doubts with us.
Cheers

[miniZ]

Sure i will give it a shot. Dont mean to come across in a rude way. Thank you guys for your work on the miner

Hi impynick,
no worries
Please, give a look at the previous post and maybe also in the FAQ.
Hope it addresses some of your questions.
Cheers

[miniZ]

tried two servers in different way:

miniz.exe --par=192,7 --pers=auto --url=user@pool1:2144 --pass c=BTC,mc=SAFE/YEC/ARW --url=user@pool2:2192 --pass c=BTC,zap=ZER/SAFE/VDL,d=8

this way miniz sees two pools, but...password for second pool is used for pool1 too...I did not find any examples with password from your miniz.ch.

Hi somaton,
Yes, we were going to tell you that it is possible but you'll neet to use --url syntax. You managed to find it! 

However, as you mention the password will be set equal for both. In this case, the only way to do it is by creating a configuration file.
This is not as difficult as it may sound.

Here the guidelines:

1. Add --write-config to your command line, and run. (add your information):
   

Code:

miniz.exe --par=192,7 --pers=auto --url=user_xxx.worker@poolserver1:2144 --pass x  --url=user2_xxx.worker@poolserver2:2144 --pass x --write-config

     miniZ will create miniZ.conf file...with both pass equal. You'll need to edit the file and correct it.

     Note that ff you want to give it a different name, then add filename.conf to command line, right after the --write-config:
     

Code:

miniz.exe --par=192,7 --pers=auto --url=user_xxx.worker@poolserver1:2144 --pass x  --url=user2_xxx.worker@poolserver2:2144 --pass x --write-config filename.conf 

2. Open your config file with a text editor. Go to  "Servers", and edit/correct the "pass" as you need, and save.
   
3. Then you'll only need to run miniZ with --read-config.
   
    If you want to read from the default file name:
     

Code:

miniZ.exe --read-config 

   

    or if you want to read from another file:
   

Code:

 miniZ.exe --read-config filename.conf

Hope this helps!
Let us know if you managed to get it to work. We'll create a FAQ for the two pass, thanks!
Cheers

[miniZ]

Any appeal to the GPUZ causes the miner to crash.
 Confuses memory used-3067mb
(in version 1.5t) 2692mb respectively.

Hi Ziv1,
Sorry but we are not fully understanding the problem.
Could you paste here your command line? And the start of your log?

Are you mining ZEL with 1060 3GB? Could it be that you are forcing a mode and it is not working?
Not sure that this is the case but the 1060 3GB, with ZEL, only works with modes= [0,10,14], mode 10 is for Windows 10 and it not as fast.

Cheers