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
