Pages:
Author

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

member
Activity: 690
Merit: 17
Just an FYI, v1.5q5 still lost connection 'can't connect to any pool'. I lost 45 mins mining time.
Hi ARTRN,
we have been checking all connection errors.
It seems that you lost connection to all your pools.
Could you let us know which coin are you mining and to which pool?
This can help us to further check if there can be any issue.
Thanks!
Cheers
jr. member
Activity: 238
Merit: 3
newbie
Activity: 47
Merit: 0
Found the unit and the rejected, coincidence?
newbie
Activity: 47
Merit: 0
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
newbie
Activity: 137
Merit: 0
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!
jr. member
Activity: 238
Merit: 3
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:
Quote
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
newbie
Activity: 63
Merit: 0
Just an FYI, v1.5q5 still lost connection 'can't connect to any pool'. I lost 45 mins mining time.
member
Activity: 690
Merit: 17
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
member
Activity: 690
Merit: 17
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
member
Activity: 690
Merit: 17
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
member
Activity: 690
Merit: 17
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
jr. member
Activity: 238
Merit: 3
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
Quote
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
Quote
[ 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
Quote
[ 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
Quote
[ 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
newbie
Activity: 54
Merit: 0
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
newbie
Activity: 54
Merit: 0
any way you could add exchangecoin EXCC its 144,5 algo? Please
jr. member
Activity: 312
Merit: 2
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)
newbie
Activity: 137
Merit: 0


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
member
Activity: 690
Merit: 17
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
member
Activity: 690
Merit: 17
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://bitcointalksearch.org/topic/claymores-dual-ethereum-amdnvidia-gpu-miner-v150-windowslinux-1433925
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
jr. member
Activity: 312
Merit: 2
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.
newbie
Activity: 24
Merit: 0
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. Smiley
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://bitcointalksearch.org/topic/claymores-dual-ethereum-amdnvidia-gpu-miner-v150-windowslinux-1433925
Pages:
Jump to: