Pages:
Author

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

member
Activity: 690
Merit: 17
On 144.5 hashrate has dropped slightly on polaris cards in v1.5
Hi Divinity666,
could you please confirm that it is a Polaris card and let us know the exact model?
miniZ is a CUDA miner, it does not support AMD cards. Smiley
Cheers
member
Activity: 690
Merit: 17
Good day.
Before loading the miner, the control and monitoring parameters of the GPU (AB MSI, GPUZ) are loaded.
I fix the availability of PhysX before and after the miner launchesccording to the testimony of the GPUZ.
Please comment.
Hi Ziv1,
Sorry, we think we may have not understood exactly what is your problem.
Could you please try to elaborate a bit more.
Why do you want to run miniZ and PhyX at the same time?
Thanks.
Cheers
member
Activity: 690
Merit: 17
Hey. If we have specified pers and par, will it still correctly auto-switch to BHII when the fork occurs?

These are the parameters we currently use:
  --par 150,5 --pers auto

Many thanks,

-- edit --

Have done some research. It looks like when you set the algo or the par, it completely ignores the forkheight and blockheight data in the stratum protocol. Our custom pool is obviously not in your magic list of URLs which support the auto detection of algo etc, so we have to specify the algo or it just mines with BitcoinGold params. Is there a commandline flag we can use to enable the auto switch???

If possible could you add it so that on the following address/port combos, it picks up Beam automatically:
proxy.cudopool.com:5317
staging.proxy.cudopool.com:5317
Hi strideynet2,
In standard cases, standard mining pools, the miner will switch to the new BeamHashII.
When autoswitch is enabled the miner will check if the fork happened and if not it gives you a message
Code:
[INFO   ] Beam not forked yet (319529<321321), switch to BeamHashI.
It switches to the old, but when the fork happens it will switch back again.

On a custom pool, if you start miniZ v1.5p with --par 150,5 --pers auto this may not happen.

In your special case try to add --pers beam before the --pers auto.
Meaning, try this:
--par 150,5 --pers beam --pers auto

If you want, we can add your pool, for the next release. Smiley

Let us know how if this helps.
Cheers
newbie
Activity: 7
Merit: 0
Hey. If we have specified pers and par, will it still correctly auto-switch to BHII when the fork occurs?

These are the parameters we currently use:
  --par 150,5 --pers auto

Many thanks,

-- edit --

Have done some research. It looks like when you set the algo or the par, it completely ignores the forkheight and blockheight data in the stratum protocol. Our custom pool is obviously not in your magic list of URLs which support the auto detection of algo etc, so we have to specify the algo or it just mines with BitcoinGold params. Is there a commandline flag we can use to enable the auto switch???

If possible could you add it so that on the following address/port combos, it picks up Beam automatically:
proxy.cudopool.com:5317
staging.proxy.cudopool.com:5317
jr. member
Activity: 312
Merit: 2
On 144.5 hashrate has dropped slightly on polaris cards in v1.5
newbie
Activity: 25
Merit: 1
Good day.
Before loading the miner, the control and monitoring parameters of the GPU (AB MSI, GPUZ) are loaded.
I fix the availability of PhysX before and after the miner launchesccording to the testimony of the GPUZ.
Please comment.

member
Activity: 690
Merit: 17
Hi everyone,
Thank you for your feedback and support!

You can find new miniZ v1.5p here.

miniZ has released a new version v1.5p that supports 150,5,3 – BeamHashII.
For more information on Beam mining check How to mine Beam? on our FAQ page.

 * Added support for 150,5,3 (BeamHashII).
 * Added autoswitch for Beam fork at block 321321.
 * Fixed ZEL mining on 3GB GPU, on Windows 10. (Testing)
 * Improved support for 210,9 (Aion).
 * Added --stat-int option to customize statistics interval.
 * Added --nonvml option to disable GPU health stats.
 * Improved cpu load.
 * Minor bug fixes.

Equihash 150,5,3 (BeamHashII):
 * GTX 1050 Ti 4GB ~11.9 Sol/s
 * GTX 1060 3GB ~20.1 Sol/s
 * GTX 1070 Ti 8GB ~40.1 Sol/s
 * GTX 1080 8GB ~41.0 Sol/s
 * GTX 1080 Ti 11GB ~53.8 Sol/s
 * RTX 2070 8GB ~46.9 Sol/s

Download here.
For additional information check our Usage or FAQ pages.
Hive OS support here.

Happy mining!
member
Activity: 690
Merit: 17
Does the program support Beam Hard Fork 15 aug?
Hi Galat,
Yes! Smiley
We have just released miniZ v1.5p that supports Beam new algo (150,5,3).
Cheers
member
Activity: 690
Merit: 17
Good day.
Why, after starting the miner, the use of is not available PhysX.
Hi Ziv1,
the miner uses all GPU resources. Are you trying to run some other software simultaneously?
Cheers
member
Activity: 690
Merit: 17
Code:
Error: recieve has been  2284
[INFO   ]stratum.icemining.ca Disconnecting
[INFO   ]stratum.icemining.ca Stopping miner

got this error couple times. Sometimes the number is different
Hi fistsofgod,
we fixed this error in the new release, miniZ v1.5p.
Thanks!
Cheers
newbie
Activity: 18
Merit: 0
newbie
Activity: 25
Merit: 1
Good day.
Why, after starting the miner, the use of is not available PhysX.
newbie
Activity: 164
Merit: 0
Code:
Error: recieve has been  2284
[INFO   ]stratum.icemining.ca Disconnecting
[INFO   ]stratum.icemining.ca Stopping miner

got this error couple times. Sometimes the number is different
member
Activity: 690
Merit: 17

for me miniZ have less CPU utilisation on 12x1070 CPU3930 4Gb ubuntu 16 cuda 9.2
Hi topteam,
thank you for letting us know.
Which nvidia driver version are you using?
Cheers
member
Activity: 690
Merit: 17
Your miner gets gradually slow on systems with many GPUs. It starts off with higher hashrate for the first few minutes and then slowly drops by up to 30% in speed. This is a sign of too much driver comms, keeping the CPU swamped with irq requests (Gminer had the same problem a few months ago but they fixed it).

You should find a way to drop CPU utilization and driver usage. You should also add an option to disable nvml polling of temperature, fans, power etc.

13x gtx1070, i3-7100, 8 GB ram, Ubuntu x64, nvidia 415.27, cuda 10.0

Gminer 150,5: 280-290 H/s, steady. CPU utilization is 40-50%. I can communicate with the GPUs while it's mining as usual.

miniZ 150,5: starts at ~250 H/s for a about 1 minute, then gradually drops to ~180 H/s within ~2 minutes. CPU is kept at 100% at all times and any GPU command issued hangs (e.g. nvidia-smi hangs entirely). The nvidia driver is totally hogged.

I tried lowering --intensity and the CPU utilization drops, but the hashrate drops significantly too, even if I use --intensity 99. Max I can get is about ~195 H/s.

I also tried --oc1 and --oc2. Also tried --telemetry 0 (doesn't disable nvml polling). Nothing made any difference (even though I have them overclocked and at lower power limits).

I'm willing to test a beta if you're willing to work on this. PM me. I manage a small farm.

EDIT: Retested Gminer on 150,5. Gets 280-290 H/s steady, with 40-50% CPU utilization.
Hi cryptoyes,
thank you so much for your availability.
We have been unable to reproduce this problem. However, we made a few changes when introducing the new Beam algo, for the next release.
Maybe you can try it and let us know if you see a difference in cpu usage. It should be out within ~24h.
We also introduce an option to disable nvml.
Cheers

member
Activity: 690
Merit: 17
why does miniZ sometimes popup a dialog box when it crashes? this results in the program stopping until I press a button and bat file loop restarts miniz and continues mining. this dialog box presents a productivity issue as I may not notice this box popup for some amount of time while the miner is doing 0 work. how can I disable this dialog box from appearing?

also: when there is a problem with a GPU it spams errors on all the GPUs so I cant identify which GPU actually caused the crash.
Hi fistsofgod,
we did a fix for the next release that may disable the popup box in your case.
You can also disable this error box by changing windows settings. Check here and let us know if it helps.
Regarding the error spamming, you need to look which GPU got the error first.
Cheers
newbie
Activity: 157
Merit: 0
Your miner gets gradually slow on systems with many GPUs. It starts off with higher hashrate for the first few minutes and then slowly drops by up to 30% in speed. This is a sign of too much driver comms, keeping the CPU swamped with irq requests (Gminer had the same problem a few months ago but they fixed it).

You should find a way to drop CPU utilization and driver usage. You should also add an option to disable nvml polling of temperature, fans, power etc.

13x gtx1070, i3-7100, 8 GB ram, Ubuntu x64, nvidia 415.27, cuda 10.0

Gminer 150,5: 280-290 H/s, steady. CPU utilization is 40-50%. I can communicate with the GPUs while it's mining as usual.

miniZ 150,5: starts at ~250 H/s for a about 1 minute, then gradually drops to ~180 H/s within ~2 minutes. CPU is kept at 100% at all times and any GPU command issued hangs (e.g. nvidia-smi hangs entirely). The nvidia driver is totally hogged.

I tried lowering --intensity and the CPU utilization drops, but the hashrate drops significantly too, even if I use --intensity 99. Max I can get is about ~195 H/s.

I also tried --oc1 and --oc2. Also tried --telemetry 0 (doesn't disable nvml polling). Nothing made any difference (even though I have them overclocked and at lower power limits).

I'm willing to test a beta if you're willing to work on this. PM me. I manage a small farm.

EDIT: Retested Gminer on 150,5. Gets 280-290 H/s steady, with 40-50% CPU utilization.
for me miniZ have less CPU utilisation on 12x1070 CPU3930 4Gb ubuntu 16 cuda 9.2
member
Activity: 297
Merit: 10
Your miner gets gradually slow on systems with many GPUs. It starts off with higher hashrate for the first few minutes and then slowly drops by up to 30% in speed. This is a sign of too much driver comms, keeping the CPU swamped with irq requests (Gminer had the same problem a few months ago but they fixed it).

You should find a way to drop CPU utilization and driver usage. You should also add an option to disable nvml polling of temperature, fans, power etc.

13x gtx1070, i3-7100, 8 GB ram, Ubuntu x64, nvidia 415.27, cuda 10.0

Gminer 150,5: 280-290 H/s, steady. CPU utilization is 40-50%. I can communicate with the GPUs while it's mining as usual.

miniZ 150,5: starts at ~250 H/s for a about 1 minute, then gradually drops to ~180 H/s within ~2 minutes. CPU is kept at 100% at all times and any GPU command issued hangs (e.g. nvidia-smi hangs entirely). The nvidia driver is totally hogged.

I tried lowering --intensity and the CPU utilization drops, but the hashrate drops significantly too, even if I use --intensity 99. Max I can get is about ~195 H/s.

I also tried --oc1 and --oc2. Also tried --telemetry 0 (doesn't disable nvml polling). Nothing made any difference (even though I have them overclocked and at lower power limits).

I'm willing to test a beta if you're willing to work on this. PM me. I manage a small farm.

EDIT: Retested Gminer on 150,5. Gets 280-290 H/s steady, with 40-50% CPU utilization.
newbie
Activity: 164
Merit: 0
why does miniZ sometimes popup a dialog box when it crashes? this results in the program stopping until I press a button and bat file loop restarts miniz and continues mining. this dialog box presents a productivity issue as I may not notice this box popup for some amount of time while the miner is doing 0 work. how can I disable this dialog box from appearing?

also: when there is a problem with a GPU it spams errors on all the GPUs so I cant identify which GPU actually caused the crash.
member
Activity: 690
Merit: 17
Thanks!

Really waiting for it. I prefer miniZ over any other miner as you know.
Thanks for your preference Smiley
Cheers
Pages:
Jump to: