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

Hi somaton,

You can use --pci-order, this will display the GPU pci bus numbers.

Feel free to let us know if you are running two instances because you experience issues with miniZ.

Cheers

Is it possible to do something with this behaviour: i have 2 gpus and running them separately in two miniz windows. The problem is - in both miniz windows gpu number shown as 0. Any way to see real gpu number? That way like it is now it is just useless.

Hi cryptoyes,

sorry, the driver version is 440.64.

miniZ Cuda 10.0, Linux kernel 5.4.0-37-generic and cpu Intel(R) Pentium(R) CPU G4560 @ 3.50GHz. We can only test up to 5 GPUs so it is hard to fully test with higher GPU load.

However, from what you described it really looks like that it could be the oc settings causing the driver to misbehave. Also, each miner may require different OCs settings since the kernels are different and exploit the GPU in different ways.

Have you had the chance to observe the same problem with miniZ on other algos?

Having said this, we will keep looking into it and we will do our best to replicate/fix/understand all the issues that everyone reports, the one you described is obviously something we'll keep an eye on. Even now that you said you managed to get it to work by increasing PL.

Thanks a lot for your feedback!

Cheers

Care to give a link to that driver for Linux? I only found 440.82.

Also, what CUDA version, kernel version, CPu and number of GPUs are you using?

CPU utilization is not from the miniz executable itself, but from the drivers. If the executable doesn't efficient CUDA calls then the nvidia driver gets hogged and kworkers end up killing the CPU. This is amplified by the number of GPUs. If you only use a few GPUs then you'll never see a problem.

There is nothing wrong with my setup, proof being that Gminer has no issues whatsoever on the exact same algo. The issue is from miniz.

my pleasure. i have forced to stop the pool temporarily but it will be back up soon.
good luck in making the most optimised miner for BH3!

Hi cryptoyes,

thank you for sharing your issue in the forum and for letting us know that you managed to resolve the it. We had observed something similar, and adjusting OCs (beside PL) helps. We never experienced problems in stock settings. Usually it is good to test in stock settings just to clarify if it can be a OCs/PL problem.

Regarding the cpu usage, possibly nvidia driver crashes and cpu goes up. miniZ does not use the CPU for any significant work. The usage should be very low. If it is using too much CPU there is something wrong, either with miniZ or with your setup.

The driver we use at the moment with the 1080Ti is 440.94 440.64^* and it works well. Also, we haven't tested it with all GPU models. Maybe someone might post here their experience with other versions.

f11 was to be used with 144,5 only, but it will be deprecated.

In the next version you will be able to use --ocX in 150,5 mining, for miniZ to find the best kernel for your OCs. However, reasonable OCs must still apply.

Cheers

^*edited

Hi rgsnedds,

Thank you for the testnet. We were about to inquire about it. This is very useful!

We already tested a bit, and both miniZ and your pool appear to be working fine. We expect to use it a lot until the algo change

Cheers

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