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

[rgsnedds]

I can't get this to work on GTX 1650 4GB , Win10 64, latest Nvidia drivers.
any ideas?

install a mining OS ditch windows.

[1713852106]

1713852106

[1713852106]

1713852106

[1713852106]

1713852106

[1713852106]

1713852106

[miniZ]

Hello,

thanks for the answer.
I installed vc_redist.x64.exe of Visual Studio 2015, 2017 and 2019 from https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads but it didn't change anything :/

Hi Dark Oopa,
We will investigate this. However, we'll add a Cuda 8 for Windows very soon, version 1.6v3.
We stopped supporting Cuda 8 but it should be working. Maybe this will take care of your issue for now.
Cheers

[miniZ]

Hi Ziv1,
for Zel and 1060 3GB, the oc2 in the newest version uses a similar kernel to the one in version 1.5t.
If you experienced stability or latency issues with v1.5t then it is good to try the recent version. But if not, if the v1.5t is working well for you, and you are just mining ZEL, then there is no reason to do it.
We will try to reduce the kernel in future versions so that the 1060 3GB may also benefit in performance.
Thank you for your feedback!
Cheers

miniZ.exe --url=ssl://user@127.0.0.1:11005 --par=beam3 --pers=Beam-PoW --extra --latency --oc0 --show-mode

************ miniZ v1.6v2 ************
Number of CUDA[10.0] devices found: 1
Algo:           EQ[beam3]
Pool#0:         user[user]
                server[127.0.0.1] port[11005] ssl[yes] pers[Beam-PoW]
Telemetry:      [http://localhost:20000]
Optimisation:   oc0[0]
Temp. limit:    [90°C]
miniZ<144,5s>[00:0:00:3318]: Selecting GPU#0[0] GeForce GTX 1650
[FATAL  ] GPU[0] has invalid mode 0.
[INFO   ] Disconnecting from 127.0.0.1
[INFO   ]127.0.0.1 Stopping miner


****************
GPU 0 HAS INVALID MODE 0!!!
--oc0  --oc1 --ocx  all don't work.
I can't get this to work on GTX 1650 4GB , Win10 64, latest Nvidia drivers.
any ideas?

Hi deskcube,
sorry, we did not test on that GPU, but we understand what is the issue.
We are finalising a fix (1.6v3) and it will be out shortly.
Mind you that rgsnedds has a point - performance on Windows will not be as high, because the solver memory will be a bit tight for the 1650 4GB.
Thanks a lot for the feedback!
Cheers

[Kringel]

BeamV3 suddenly stopped working on Nicehash with --pers=auto (all shares are rejected); when --pers=Beam-PoW or is not specified at all miniZ still works fine.

[miniZ]

BeamV3 suddenly stopped working on Nicehash with --pers=auto (all shares are rejected); when --pers=Beam-PoW or is not specified at all miniZ still works fine.

Hi Kringel,
This is fixed now. We also spotted that issue and we just released version v1.6v3 with a few corrections. Are you using this version already? --pers auto is fine again on NiceHash.
Cheers

[miniZ]

Hi everyone,

we released a new miniZ version with a few adjustments and fixes.

Please find miniZ version 1.6v3 @ Download page.


Changelog:

* removed autoswitch for Beam.
* no need to add --par when mining to pool.raskul.com or beamv3.nicehash.com.
* fixed --pers auto that was not working on NiceHash
* added support for GTX 1650 4GB, in BeamHash III.
* added a few corrections to 144,5 that we expect to benefit miners experiencing high cpu usage. (Let us know if this helped)

This was only possible with your feedback. Thank you!

We'll keep working to make miniZ better.

Happy mining!

[deskcube]

Thank you very much, MiniZ.  You guys are great.  Its good advice too but i want to alt tab to my eve online and playstation emulator. LOL.  i guess i should go and install some other OS soon.

[rainbowminer]

There is a bug in the new v1.6v3 when mining on Nicehash. The miner seems to alter the selected algorithm from "--par=144,5s" to "150,5,3" causing 100% rejected shares on Nicehash:

This is the commandline:
miniZ.exe --telemetry 33000 -cd 0 1 4 --server beamv3.eu.nicehash.com --port 3387 --user 3M73gP6x55C7nws3ie7UwCHpy5tDDVLwHN.GTX1660TIs --pass x --pers Beam-PoW --gpu-line --extra --latency --nocolor --par=144,5s

This is what happens:

[miniZ]

There is a bug in the new v1.6v3 when mining on Nicehash. The miner seems to alter the selected algorithm from "--par=144,5s" to "150,5,3" causing 100% rejected shares on Nicehash:

This is the commandline:
miniZ.exe --telemetry 33000 -cd 0 1 4 --server beamv3.eu.nicehash.com --port 3387 --user 3M73gP6x55C7nws3ie7UwCHpy5tDDVLwHN.GTX1660TIs --pass x --pers Beam-PoW --gpu-line --extra --latency --nocolor --par=144,5s

This is what happens:

Hi rainbowminer,
We tested your command line and it is working well.

We have an idea about what can be happening: can you confirm that you wrote the 's' in --par=144,5s ? It seems that you may have copied/wrote without the 's'.
However, if we use --par=144,5 instead of --par=144,5s we have the same output as you have.

You can also use --par=beam3 that may be more user friendly.
 
Let us know if this helped.
Thank you for the feedback. We'll try to make miniZ 'smarter' in the next version to help avoid this issues.
Cheers

[Dark Oopa]

Hello,

thanks for the answer.
I installed vc_redist.x64.exe of Visual Studio 2015, 2017 and 2019 from https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads but it didn't change anything :/

Hi Dark Oopa,
We will investigate this. However, we'll add a Cuda 8 for Windows very soon, version 1.6v3.
We stopped supporting Cuda 8 but it should be working. Maybe this will take care of your issue for now.
Cheers

Hello, I tried the v3, cuda 10 and cuda 8, and for both, windows message "miniz.exe is not a valid Win32 application"
it works well with t2 but u2 does the same message as v2 or v3 :/

[rainbowminer]

There is a bug in the new v1.6v3 when mining on Nicehash. The miner seems to alter the selected algorithm from "--par=144,5s" to "150,5,3" causing 100% rejected shares on Nicehash:

This is the commandline:
miniZ.exe --telemetry 33000 -cd 0 1 4 --server beamv3.eu.nicehash.com --port 3387 --user 3M73gP6x55C7nws3ie7UwCHpy5tDDVLwHN.GTX1660TIs --pass x --pers Beam-PoW --gpu-line --extra --latency --nocolor --par=144,5s

This is what happens:
..

Hi rainbowminer,
We tested your command line and it is working well.

We have an idea about what can be happening: can you confirm that you wrote the 's' in --par=144,5s ? It seems that you may have copied/wrote without the 's'.
However, if we use --par=144,5 instead of --par=144,5s we have the same output as you have.

You can also use --par=beam3 that may be more user friendly.
 
Let us know if this helped.
Thank you for the feedback. We'll try to make miniZ 'smarter' in the next version to help avoid this issues.
Cheers

Yes, I can confirm, that I am using the --par=144,5s - including that s. It does not happen on all of the rigs. My GTX1070 rigs work perfect, but I have at least two users, that happen to have this problem. Since it's the same RainbowMiner release on all the rigs, the commandline is the same for everybody.

The above example happens to one of the RainbowMiner users.
Interesting enough, it says [144,5] in the first line, but the GPUs are started on <150,5,3> - and all that with --par=144,5s.

So for some reason MiniZ seems to change the algorithm sometimes, when starting on Nicehash. Is there any logic build-in, that checks for Nicehash perimeters and then would do such a smartswitch?

[miniZ]

Hello, I tried the v3, cuda 10 and cuda 8, and for both, windows message "miniz.exe is not a valid Win32 application"
it works well with t2 but u2 does the same message as v2 or v3 :/

Hi Dark Oopa,
This error could be related to file being corrupted or missing.
Because of incomplete download or even the antivirus software...

You can calculate checksum SHA256 of the file miniZ.exe, and compare with what we have in the download page. If they differ then you should download the file again. And check SHA256 again please.

On Win10 there is Get-FileHash command on powershell, but it does not exist (it seems) on Windows 7. We tried hashtab on Win7 and worked fine - http://implbits.com/products/hashtab/ . There are others for sure.
 
We'll continue think of other possibilities.
Let us know how it goes.
Cheers

[george2019]

-pers auto --ocX also working fine :



very stable and good hashrate, zelhash algo working good as well with 230 sols using same oc settings, i also had problems using --par=144,5s hashrate was very low after few minutes, now working fine

[miniZ]

Yes, I can confirm, that I am using the --par=144,5s - including that s. It does not happen on all of the rigs. My GTX1070 rigs work perfect, but I have at least two users, that happen to have this problem. Since it's the same RainbowMiner release on all the rigs, the commandline is the same for everybody.

The above example happens to one of the RainbowMiner users.
Interesting enough, it says [144,5] in the first line, but the GPUs are started on <150,5,3> - and all that with --par=144,5s.

So for some reason MiniZ seems to change the algorithm sometimes, when starting on Nicehash. Is there any logic build-in, that checks for Nicehash perimeters and then would do such a smartswitch?

Hi rainbowminer,
the command line that you gave is working but it does not seem to be the one that is really being used.
Could you (somehow) check what is the real command line being sent to miniZ?
 
The only special logic associated with nicehash... is that if the pool name contains beamv3 miniZ will load the algo 144,5s but only if the par argument is not specified.
 
Also, there was an override that was changing the algo to 150,5,3 when there was beam on the pool name. This was needed for the autoswitch to work properly for most people, and will be removed on the next version. But it does not happen if you write --par=144,5s.

It seems that --par=144,5 (without the s) is sent to the miner -  Algo:   EQ[144,5].
You can see that if you write something else like xxxx, that will appear between brackets.

Could it be that the last character of the command is being dropped in some version of Windows Powershell?
Maybee the best is not to specify --par at all.

It is hard to help, we cannot reproduce your issue. Can you reproduce this on your rigs? 
Cheers

[miniZ]

-pers auto --ocX also working fine :


very stable and good hashrate, zelhash algo working good as well with 230 sols using same oc settings

Hi george2019,
thank you for sharing!
Cheers

[rainbowminer]

Yes, I can confirm, that I am using the --par=144,5s - including that s. It does not happen on all of the rigs. My GTX1070 rigs work perfect, but I have at least two users, that happen to have this problem. Since it's the same RainbowMiner release on all the rigs, the commandline is the same for everybody.

The above example happens to one of the RainbowMiner users.
Interesting enough, it says [144,5] in the first line, but the GPUs are started on <150,5,3> - and all that with --par=144,5s.

So for some reason MiniZ seems to change the algorithm sometimes, when starting on Nicehash. Is there any logic build-in, that checks for Nicehash perimeters and then would do such a smartswitch?

Hi rainbowminer,
the command line that you gave is working but it does not seem to be the one that is really being used.
Could you (somehow) check what is the real command line being sent to miniZ?
 
The only special logic associated with nicehash... is that if the pool name contains beamv3 miniZ will load the algo 144,5s but only if the par argument is not specified.
 
Also, there was an override that was changing the algo to 150,5,3 when there was beam on the pool name. This was needed for the autoswitch to work properly for most people, and will be removed on the next version. But it does not happen if you write --par=144,5s.

It seems that --par=144,5 (without the s) is sent to the miner -  Algo:   EQ[144,5].
You can see that if you write something else like xxxx, that will appear between brackets.

Could it be that the last character of the command is being dropped in some version of Windows Powershell?
Maybee the best is not to specify --par at all.

It is hard to help, we cannot reproduce your issue. Can you reproduce this on your rigs?  
Cheers

Thank you for your help and reply. That helps a lot. The problem is, the url is exactly the one, that will be passed down to the miner. So something really strange is going on, here. I feel, that the comma might cause the trouble, since powershell sometimes transforms and interprets a bit wild.

Anyway, keep up the good work

[Dark Oopa]

Hello, I tried the v3, cuda 10 and cuda 8, and for both, windows message "miniz.exe is not a valid Win32 application"
it works well with t2 but u2 does the same message as v2 or v3 :/

Hi Dark Oopa,
This error could be related to file being corrupted or missing.
Because of incomplete download or even the antivirus software...

You can calculate checksum SHA256 of the file miniZ.exe, and compare with what we have in the download page. If they differ then you should download the file again. And check SHA256 again please.

On Win10 there is Get-FileHash command on powershell, but it does not exist (it seems) on Windows 7. We tried hashtab on Win7 and worked fine - http://implbits.com/products/hashtab/ . There are others for sure.
 
We'll continue think of other possibilities.
Let us know how it goes.
Cheers

hello,

this was the problem. Weird that it was present for v2, v3 and u2, I suppose there was a problem with windows or 7zip that has been fixed when I rebooted the coputer this week.

Thanks for your help.

just one thing, on mining rig rental, my 2 miners stopped when the rental ended.
I use --smart-pers and I didn't have problem with older versions since this option came up.
We will see next rental if there is a problem there.

thx

[miniZ]

hello,

this was the problem. Weird that it was present for v2, v3 and u2, I suppose there was a problem with windows or 7zip that has been fixed when I rebooted the coputer this week.

Thanks for your help.

just one thing, on mining rig rental, my 2 miners stopped when the rental ended.
I use --smart-pers and I didn't have problem with older versions since this option came up.
We will see next rental if there is a problem there.

thx

Hi Dark Oopa,
Thank you for the feedback!

Let us know if you experience any issue again with mining rentals. If possible, provide the log information and we'll have a look.
Cheers

[crsminer]

Hi miniZ!

Great work as always!

Can you confirm that GTX 970 works?

It's stuck at.. miniZ_144,5s_[01:0:00:3957]: Selecting GPU#1[1] GeForce GTX 970

Thx!

[miniZ]

Hi miniZ!

Great work as always!

Can you confirm that GTX 970 works?

It's stuck at.. miniZ_144,5s_[01:0:00:3957]: Selecting GPU#1[1] GeForce GTX 970

Thx!

Hi crsminer,
Thank you for your support!

We were expecting the GTX 970 to work well.

Just in case...could it be that you forgot to add ssl to server address?

To exclude issues with pool connection, you can try mining to a different pool and see if you observe the same behavior.

You can also try to load a different kernel with --mode option, example: --mode=0.

If these do not help, could you paste here your command line and the start of your log?

Cheers