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

[miniZ]

Hello
I posede two rtx card 2060 one asus and the other msi aventus oc
can you help me find the right oc to exploit the beam BeamHashII I'm on cudominer
know the tdp? clokc? memory
for msi it is impossible to load the tdp below 78
tanks you

Hi devivier,
Unfortunately we do not have a 2060 card so we cannot share any values.
These are the ones we usually have an easy access to.
The tables are updated when we make changes to miner, so it is good to check it every now and then for updated values.

We did a search and found this forum discussion https://forums.anandtech.com/threads/help-overclocking-rtx-2060.2562400/.
Maybe this can help you get started in finding the best OC values for your card and configuration.

Hope this helps.
Cheers

[miniZ]

Hi,
What is the command of these parameters?

retry counts
retry delay
job timeout

Awesomeminer would close the miniz in case of a connection error even if it was for 30 minutes or less!

Hi Asusrogmining,
if we correctly understood your question, miniZ does not have a command for these parameters.
Maybe you could elaborate a bit more and let us know if you need us to add some features.
Thanks.
Cheers

[Asusrogmining]

Hi,
What is the command of these parameters?

retry counts
retry delay
job timeout

Awesomeminer would close the miniz in case of a connection error even if it was for 30 minutes or less!

Hi Asusrogmining,
if we correctly understood your question, miniZ does not have a command for these parameters.
Maybe you could elaborate a bit more and let us know if you need us to add some features.
Thanks.
Cheers

Thanks for the reply. In the case of a connection error, miniz closes itself after some tries for the re-connection. Almost all well-know miners have these parameters. By increasing the number of retries and also increasing the timeout, the miner remains open if a connection error occurs. Please take a look at Claymore:

https://bitcointalk.org/index.php?topic=1433925.0

[Divinity666]

Hi Divinity666,
Thank you for the feedback.
Tomorrow we will update beta version, could you try it out then and check if you still have the same issue with the miner stopping too long when it loses connection?
Cheers

Why would it lose connection in the first place? I'm testing with gminer now for almost 20hours and it doesn't lose connection at all, not even for a second.

[miniZ]

Thanks for the reply. In the case of a connection error, miniz closes itself after some tries for the re-connection. Almost all well-know miners have these parameters. By increasing the number of retries and also increasing the timeout, the miner remains open if a connection error occurs. Please take a look at Claymore:

https://bitcointalk.org/index.php?topic=1433925.0

Hi Asusrogmining,
The miner does not exit, it only stops mining if cannot establish connection and only until it reconnects.
It continuously tries 3 times and then waits a few seconds before another 3x series.

We'll have a look and see how to implement these as parameters for user to set.
Thanks for the suggestion.
Cheers

[miniZ]

Hi Divinity666,
Thank you for the feedback.
Tomorrow we will update beta version, could you try it out then and check if you still have the same issue with the miner stopping too long when it loses connection?
Cheers

Why would it lose connection in the first place? I'm testing with gminer now for almost 20hours and it doesn't lose connection at all, not even for a second.

Hi Divinity666,
losing connection to pool is not uncommon, even for other miners.
Reasons, can be on user side like newtork instability, even if momentaneous (or not).
It can also depend on the pool. The pool may disconnect if it does not receive any shares for some time. The pool may disconnect or reset the connection for some other reason.

We made available a beta version v1.5q4 that should be more efficient in reconnecting to pool.
Let us know how it goes. Thanks a lot for your feedback and patience.
Cheers

[BigHarryArmsi]

Hi BigHarryArmsi,
how is it going with the OCs?

Based on some values that people have been sharing around we realize that PL~70% (give or take 5%) is the most common power used by miners.
We tried some values for clocks core and memory for the 1080 that we share here for your (and others) reference.
1080: PL=70% (126W), core=+150, memory=+900 resulted in ~40.7 Sol/s. T~65C, Fan~42%.

Tomorrow we plan an update to beta version, could you try then the 1060 6GB and check if there was any improvement?
Thanks!
Cheers

Thanks, miniZ
Lay it on me! Your miner is running steady as usual but these cards are not happy as there are too many invalids and low hash rate, so I am happy to give your update a try. Maybe paste a new command here as those things always cross me up... >lazy is suppose, too<
Running 150 and 500 now at 65% and over time the hash rate is slowly diminishing but this miner is dead steady, otherwise

[Divinity666]

Hi Divinity666,
losing connection to pool is not uncommon, even for other miners.
Reasons, can be on user side like newtork instability, even if momentaneous (or not).
It can also depend on the pool. The pool may disconnect if it does not receive any shares for some time. The pool may disconnect or reset the connection for some other reason.

We made available a beta version v1.5q4 that should be more efficient in reconnecting to pool.
Let us know how it goes. Thanks a lot for your feedback and patience.
Cheers

In v1.5q4 issue still persists. I got 2 minutes of idle after 20 minutes of running a miner(and 3 minutes after submitting last share)

ps Well gminer doesn't lose connection thats a fact, I've tested for a 24+hours...

pps upd. ok, now its 1 minute of idle, I was wrong, it actually went down from 2 minutes. Still would like miner not to stop mining in the first place. Other miners I've tried don't have that issue, so its not pool error or something like that.

ppps upd2. turns out idle time varies, sometimes its 1 minute and sometimes its over 2 even(like 140 seconds or so)

[sharmanov]

any way you could add exchangecoin EXCC its 144,5 algo? Please

[sharmanov]

Something terribly wrong with the latest test-release 1.5q4 only half the accepted shares are being accounted for on the poolside. for BeamHash II

[darkneorus]

Could you just confirm that mode 3 was selected? Should appear something like this in the beginning of output:
miniZ<150,5,3>[3:1:00:3933]: Selecting GPU#0[0] P104-100

yup
GPU Bus load, reported by GPU-Z, also varies from 7 to 16%, with worst performing GPUs using less bus bandwidth.

Hi darkneorus,
we just released a v1.5q3 beta version.
Could you check if there is any improvement for the P104?
Thanks.
Cheers

there is some improvement but performance is still far behind GMiner.

GMiner

00:58:31 Speed: GPU0 41.1 Sol/s GPU1 27.9 Sol/s GPU2 26.8 Sol/s GPU3 39.8 Sol/s GPU4 41.4 Sol/s GPU5 40.7 Sol/s GPU6 41.2 Sol/s GPU7 41.2 Sol/s GPU8 40.8 Sol/s

without --oc

[ 0d 0h 4m52s|00:42:45 04/09/2019] S:173/0 234(233.9)Sol/s 1153(1163.0)W [beamv2.eu-new.nicehash.com]- 83ms (91.8%) (8.2%)
 0>P104-100     ` 100% [54°C/83%] 15.88 I/s 32.0(31.9)Sol/s 165(169.9)W clk=1809MHz mclk=5005MHz Sol/W=0.19 1.999 Sol/I
 1>P106-100     ` 100% [46°C/125%]  7.82 I/s 15.9(15.8)Sol/s  65( 77.5)W clk=1949MHz mclk=4303MHz Sol/W=0.20 2.019 Sol/I
 2>P106-100     ` 100% [49°C/88%]  7.64 I/s 15.1(15.0)Sol/s 100( 86.6)W clk=1923MHz mclk=4303MHz Sol/W=0.17 1.949 Sol/I
 3>P104-100     ` 100% [52°C/57%] 14.29 I/s 28.6(28.6)Sol/s 121(132.8)W clk=1847MHz mclk=5005MHz Sol/W=0.22 1.982 Sol/I
 4>P104-100     ` 100% [56°C/83%] 14.51 I/s 29.6(29.6)Sol/s 143(141.4)W clk=1873MHz mclk=5005MHz Sol/W=0.21 2.029 Sol/I
 5>P104-100     ` 100% [51°C/89%] 14.20 I/s 28.0(28.1)Sol/s 143(140.3)W clk=1847MHz mclk=5005MHz Sol/W=0.20 1.968 Sol/I
 6>P104-100     ` 100% [57°C/84%] 14.27 I/s 28.4(28.4)Sol/s 134(137.4)W clk=1835MHz mclk=5005MHz Sol/W=0.21 1.992 Sol/I
 7>P104-100     ` 100% [52°C/82%] 14.41 I/s 28.6(28.7)Sol/s 143(139.5)W clk=1898MHz mclk=5005MHz Sol/W=0.21 1.997 Sol/I
 8>P104-100     ` 100% [50°C/85%] 14.45 I/s 28.1(28.2)Sol/s 139(137.7)W clk=1898MHz mclk=5005MHz Sol/W=0.20 1.959 Sol/I

--oc1

[ 0d 0h 3m51s|00:33:07 04/09/2019] S:115/0 217(217.2)Sol/s 1059(1076.2)W [fee.server]- 72ms (93.5%) (6.5%)
 0>P104-100     ` 100% [52°C/85%] 15.08 I/s 29.7(29.7)Sol/s 166(161.6)W clk=1835MHz mclk=5005MHz Sol/W=0.18 1.968 Sol/I
 1>P106-100     ` 100% [42°C/138%]  6.57 I/s 13.1(13.1)Sol/s  66( 70.4)W clk=1949MHz mclk=4303MHz Sol/W=0.19 1.984 Sol/I
 2>P106-100     ` 100% [47°C/84%]  6.53 I/s 13.2(13.3)Sol/s  63( 65.3)W clk=1923MHz mclk=4303MHz Sol/W=0.20 2.049 Sol/I
 3>P104-100     ` 100% [49°C/114%] 13.44 I/s 26.1(26.1)Sol/s 118(122.2)W clk=1847MHz mclk=5005MHz Sol/W=0.21 1.947 Sol/I
 4>P104-100     ` 100% [52°C/82%] 13.61 I/s 27.5(27.5)Sol/s 133(132.5)W clk=1885MHz mclk=5005MHz Sol/W=0.21 2.013 Sol/I
 5>P104-100     ` 100% [49°C/84%] 13.42 I/s 26.8(26.8)Sol/s 123(126.9)W clk=1847MHz mclk=5005MHz Sol/W=0.21 2.006 Sol/I
 6>P104-100     ` 100% [54°C/85%] 13.41 I/s 26.0(26.1)Sol/s 133(132.0)W clk=1835MHz mclk=5005MHz Sol/W=0.20 1.967 Sol/I
 7>P104-100     ` 100% [49°C/82%] 13.56 I/s 27.3(27.2)Sol/s 129(132.8)W clk=1911MHz mclk=5005MHz Sol/W=0.20 1.988 Sol/I
 8>P104-100     ` 100% [46°C/85%]*13.59 I/s 27.0(27.0)Sol/s 128(132.6)W clk=1898MHz mclk=5005MHz Sol/W=0.20 1.994 Sol/I

--oc2

[ 0d 0h 3m12s|00:37:03 04/09/2019] S:178/0 234(234.0)Sol/s 1163(1178.2)W [beamv2.eu-new.nicehash.com]- 168ms (100.0%) (0.0%)
 0>P104-100     ` 100% [54°C/83%] 15.89 I/s 31.1(31.1)Sol/s 174(178.1)W clk=1847MHz mclk=5005MHz Sol/W=0.17 1.957 Sol/I
 1>P106-100     ` 100% [46°C/143%]  7.82 I/s 15.8(15.8)Sol/s  64( 79.3)W clk=1949MHz mclk=4303MHz Sol/W=0.20 2.024 Sol/I
 2>P106-100     ` 100% [49°C/87%]* 7.56 I/s 14.9(14.9)Sol/s  92( 91.4)W clk=1923MHz mclk=4303MHz Sol/W=0.16 1.984 Sol/I
 3>P104-100     ` 100% [52°C/114%] 14.30 I/s 28.5(28.5)Sol/s 130(131.3)W clk=1847MHz mclk=5005MHz Sol/W=0.22 2.004 Sol/I
 4>P104-100     ` 100% [55°C/83%] 14.39 I/s 28.9(28.9)Sol/s 144(138.8)W clk=1873MHz mclk=5005MHz Sol/W=0.21 2.019 Sol/I
 5>P104-100     ` 100% [51°C/89%] 14.18 I/s 28.8(28.8)Sol/s 125(133.6)W clk=1847MHz mclk=5005MHz Sol/W=0.22 2.001 Sol/I
 6>P104-100     ` 100% [56°C/84%] 14.13 I/s 28.1(28.1)Sol/s 139(140.9)W clk=1835MHz mclk=5005MHz Sol/W=0.20 1.954 Sol/I
 7>P104-100     ` 100% [52°C/84%] 14.42 I/s 29.4(29.4)Sol/s 152(144.9)W clk=1898MHz mclk=5005MHz Sol/W=0.20 2.056 Sol/I
 8>P104-100     ` 100% [50°C/84%] 14.49 I/s 28.8(28.8)Sol/s 141(139.9)W clk=1898MHz mclk=5005MHz Sol/W=0.21 1.994 Sol/I

[miniZ]

Thanks, miniZ
Lay it on me! Your miner is running steady as usual but these cards are not happy as there are too many invalids and low hash rate,

Something terribly wrong with the latest test-release 1.5q4 only half the accepted shares are being accounted for on the poolside. for BeamHash II

Hi BigHarryArmsi, sharmanov,
thanks for the feedback!
We think that this issue is fixed in the latest v1.5q5 fix.
Could you try it out and let us know how it goes?
Cheers

[miniZ]

any way you could add exchangecoin EXCC its 144,5 algo? Please

Hi sharmanov
we'll have a look.
We will see if this is possible for the next release.
Thanks for the suggestion.
Cheers

[miniZ]

Hi Divinity666,
losing connection to pool is not uncommon, even for other miners.
Reasons, can be on user side like newtork instability, even if momentaneous (or not).
It can also depend on the pool. The pool may disconnect if it does not receive any shares for some time. The pool may disconnect or reset the connection for some other reason.

We made available a beta version v1.5q4 that should be more efficient in reconnecting to pool.
Let us know how it goes. Thanks a lot for your feedback and patience.
Cheers

In v1.5q4 issue still persists. I got 2 minutes of idle after 20 minutes of running a miner(and 3 minutes after submitting last share)

ps Well gminer doesn't lose connection thats a fact, I've tested for a 24+hours...

pps upd. ok, now its 1 minute of idle, I was wrong, it actually went down from 2 minutes. Still would like miner not to stop mining in the first place. Other miners I've tried don't have that issue, so its not pool error or something like that.

ppps upd2. turns out idle time varies, sometimes its 1 minute and sometimes its over 2 even(like 140 seconds or so)

Hi Divinity666,
we have been unable to reproduce such high idle time periods. Very ocasionally we get a few seconds down, not minutes.
It is possible that the latest fix v1.5q5 is dealing better with this issue.
We continue checking this.
Thanks for all the updates!
Cheers

[miniZ]

Could you just confirm that mode 3 was selected? Should appear something like this in the beginning of output:
miniZ<150,5,3>[3:1:00:3933]: Selecting GPU#0[0] P104-100

yup
GPU Bus load, reported by GPU-Z, also varies from 7 to 16%, with worst performing GPUs using less bus bandwidth.

Hi darkneorus,
we just released a v1.5q3 beta version.
Could you check if there is any improvement for the P104?
Thanks.
Cheers

there is some improvement but performance is still far behind GMiner.

Hi darkneorus,
thank you for all the information on the P104-100 GPU, with 150,5,3.
At the moment it is likely that v1.5q5 doesn't show a significant improvement.
We will keep working on this.
Cheers

[ARTRN]

Just an FYI, v1.5q5 still lost connection 'can't connect to any pool'. I lost 45 mins mining time.

[darkneorus]

Hi darkneorus,
thank you for all the information on the P104-100 GPU, with 150,5,3.
At the moment it is likely that v1.5q5 doesn't show a significant improvement.
We will keep working on this.
Cheers

found this at your website:

Some of you were unable to run miniZ with the NVIDIA mining series cards, on Windows. These cards require an older driver (≥382.53, depending on card and brand) that is not compatible with cuda 9.2 (see Table 1).
We made available a version compiled with cuda 8.0 for Windows for you to use with these GPUs.
Both Linux and Windows miniZ cuda 8.0 versions should run fine with the P106-100 and P104-100 GPUs across different brands.

my P106 and P104 are running with 4xx drivers and CUDA 10 without any issues. maybe you have some hacks/workarounds in your code to support CUDA 8 for them, and they are related to, or are the cause of low performance?

thank you

[BigHarryArmsi]

Thanks for the update miniZ!
All green! The sea of red has gone away, thank you.
Hash rate is still low, though. 1066s ~22, 1080 ~42
Power at 65% clocks at 150 and 450 across the board, temps are down a bit, all ~55 or lower.
1080Ti rig running all green also. Kinda slow, though. 80% power, 150 and 500 clocks generating ~57 hashes.
 
More speed!

Thanks again, miniZ

update... I must say the 1066s are very responsive to power increase. Increasing power from 65% to 75% gained 10% in hash rate!
up-update... invalids have dropped to near non-existent!

[V_I_T_A_L_Y]

Hello! please tell me I'm your miner can dig beam on the pool solo-beam.2miners.com? And then yesterday switched to your miner Mini-Z with gminer and still have not found a single block, maybe just bad luck but decided better to ask you. Not all miners are suitable for solo mining

[V_I_T_A_L_Y]

Found the unit and the rejected, coincidence?