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

Hi impynick,
We plan to improve 150,5 algo soon!
Cheers

Pushing the power up from 200W to 235W on 1080ti seems to have made a huge difference and the hashrate is not dropping any more. Do you recommend any specific driver version and cuda version for Linux for Nvidia?

testnet pool for BeamhashIII - http://testnet.raskul.com:8010/
mainnet pool with stratum-ready for BeamHashIII - https://pool.raskul.com/

feel free to use my pool for your devfee - we have designed a rewards system which benefits blockfinder with a (variable) bonus.

please see https://medium.com/@rgsnedds/beam-open-source-pool-e68bae4ca06f for more info

miniZ still humps the drivers too much (at least on Linux) ... the hashrate is fine for the first few minutes, then drops. Driver becomes unresponsive while miniZ is running, e.g. nvidia-smi doesn't respond. I reported this problem in the past. On my G4400 one core ends up used at a constant 100% while the other is practically idle (something's not right, it's as if the app ends in single-threaded mode). Shame this issue wasn't fixed.

I tried miniZ again because Gminer made a boobo and blocked all 150,5 mining because all devfee pools are unavailable and shuts down the miner.

miniZ hashes slower than Gminer to begin with (but not by a lot), but then drops by 10-25% ... on Grimm: it drops from 300 H/s to 270 H/s (9 GPUs), and on the other node it drops from 270 H/s to 210 H/s.

Gminer has no such issues. Hashes at constant rate.

ubuntu 16.04, cuda10.0, nvidia 415.28, G4400, 16GB ram, 9 GPUs on one node (mix of 1080ti and 1070) and 7 GPUs on another node (1080ti). GPUs are overclocked, but not a lot (+100 core, +800 mem). I tried without o/c as well. Hashrate still drops.

I tried all combinations of --oc1/2. --oc2 isn't supported, --oc1 lowers my hashrate directly by 20-30%. I also tried --nonvml. I also tried --intensity=99 or lower (it's unusable, even at 99 the gpu core utilization is 60% and hashrate is less than half).

p.s. I have no idea what --f11 is or does and it's not really explained. Doesn't seem to help anyway.

quick note to the marvellous miniZ devs... f you are looking to test your miner for the upcoming BeamHashIII, i have a testnet pool which is already switched

http://testnet.raskul.com:8010/

keep up the great work!

150.5 grimm improvements would win you all tthe market share over gminer

ok, now i know what you mean. I did not mention that i'm using miniz with -nocolor switch (win 8.1), so cant say how it looks without that switch with newer os, but there is no "S: 25/0" for me with 1 gpu, only after adding additional switch --show-shares now i can see what i want - S: 25/0. Thanks.

Hi somaton,
yes, it is done like this. But when you have only one GPU you can see the details in the line above, where the total appears (ex. S:  25/0). In this particular case the values are the same.
Cheers

When running only 1 gpu with switches --shares-detail --gpu-line, there is no info how many shares accepted and how many rejected, showing just 100%. Is it by design?

Hi Cryogen25,
Added!
Thank you for your suggestion.
Cheers

In your Compatible Projects list on the MiniZ website: https://miniz.ch/features/#performance
You can add SimpleMiningOS (SMOS) to the list.  Works great with MiniZ and they keep it updated. https://simplemining.net/

Hi jgonzi,
Thank you for the feedback.
Values are always great as a reference for us, and for other users.
It looks somewhat similar to our 1660 Ti.
Cheers

Hi topteam,
You are welcome.
Great that is working better this time.
Cheers

If you want to update Values in t3 with a 1660 Super

Equihash 125 (PowLimit 70%+ Core 120Mhz + Mem 900Mhz) = 27-28 Sol/s <90W
- Equihash 144 (PowLimit 70%+ Core 120Mhz + Mem 900Mhz) = 41-42 Sol/s with Miniz <90W
- Equihash 192 (PowLimit 70% + Core 120Mhz + Mem 800Mhz) =  21.5 -22.5 Sol/s with MiniZ <90W

thanks for remove alien

Hi Ziv1,
Thanks! Your log was very useful.
We will make our best to make it work for you without losing the t3 version improvements.
Cheers

************ miniZ v1.5t2 ************
Number of CUDA[10.0] devices found: 2
Algo:      EQ[125,4]
Pool#0:    userXXXXX.rigr]
      server[zel.2miners.com] port[19090] ssl[yes] pers[ZelProof]
Logging::    file[miniZ.log] period[10] delay[0]
Temp. limit:   [75шC]
miniZ<125,4>[03:0:00:2908]: Selecting GPU#0[0] GeForce GTX 1060 3GB
miniZ<125,4>[03:0:00:2908]: Selecting GPU#1[1] GeForce GTX 1060 3GB
[ 0d 0h 0m10s|07:51:09 15/05/2020] S:  0/0 40(39.9)Sol/s 161(161.3)W [zel.2miners.com]
 0>GTX 1060 3GB  100% [36шC/30%]  9.57 I/s 20.6(20.6)Sol/s  89( 88.8)W clk=1797MHz mclk=4201MHz Sol/W=0.23
 1>GTX 1060 3GB  100% [45шC/30%]  8.73 I/s 19.3(19.3)Sol/s  72( 72.4)W clk=1582MHz mclk=3802MHz Sol/W=0.27
[ 0d 0h 0m20s|07:51:18 15/05/2020] S:  0/0 39(38.6)Sol/s 157(157.4)W [zel.2miners.com]
 0>GTX 1060 3GB  100% [39шC/30%] 10.26 I/s 18.9(18.9)Sol/s  84( 84.2)W clk=1746MHz mclk=4201MHz Sol/W=0.22
 1>GTX 1060 3GB  100% [47шC/30%]  9.33 I/s 19.7(19.7)Sol/s  73( 73.2)W clk=1582MHz mclk=3802MHz Sol/W=0.27

Hi Ziv1,
There was another person with the same issue.
Thanks a lot for the feedback and for the information.
Could you also paste here the same information but from the previous version t2? This can help too.
The issue will be solved in the next version.
Cheers

************ miniZ v1.5t3 ************
Number of CUDA[10.0] devices found: 2
Algo:      EQ[125,4]
Pool#0:    user[XXXXX.rigr]
      server[zel.2miners.com] port[9090] ssl[no] pers[ZelProof]
Logging::    file[miniZ.log] period[10] delay[0]
Temp. limit:   [75шC]
miniZ<125,4>[00:0:00:2906]: Selecting GPU#0[0] GeForce GTX 1060 3GB
miniZ<125,4>[00:0:00:2906]: Selecting GPU#1[1] GeForce GTX 1060 3GB
out of memory::CUDA: failed to alloc memory for target

Version t2 works.

Hi somaton,
The miner should switch back when the first pool is back again. It may not be imediately but it usually does not take long.
We will try to reproduce the issue.
Thank you for letting us know!
Cheers