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

The problem is that in order to get a hashrate comparable to that achieved with the 1.5t3 version, I have to use both --oc1/oc2 and --mode options, at least on 1070s. --ocX alone gives inferior results; so I have to wait till it finishes and finds kinda the best mode, and then add that mode to the command line with either --oc1 or --oc2 (depending on the power limit and thermal conditions for particular cards). Not sure if that procedure gives the best possible result, but it's definitely better than just running --ocX.

Imagine my frustration: after spending a lot of time and efforts I get the same hashrate that I got with the older version literally within a minute, just by empirically selecting an appropriate kernel.

farms run under the operating system
  W 7.
For management and monitoring I use programs - AB, G P U Z.
These programs run by default.
In version 1.5u 2, when working with G P U Z (switching the viewing of video card parameters), a malfunction occurs.
In my previous post, this is shown in the work log
(there was talk about version 1.5u).
I pay attention to the-memory used parameter (in version 1.5u -1.5u 2 reaches 3067mb) v 1.5t -2692mb.
Perhaps because of this, a crash occurs.

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

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):
   
     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:
     
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:
        

    or if you want to read from another file:
   
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

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

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

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.

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

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

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

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

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?

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

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

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

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

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

[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)

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