Found the unit and the rejected, coincidence?
Topic: miniZ v2.0a Equihash 144,5 125,4 210,9 150,5 192,7 BeamHash3 ProgPoW Ethash CFX - page 37. (Read 59613 times)
September 06, 2019, 08:30:40 AM
September 06, 2019, 06:14:52 AM
Found the unit and the rejected, coincidence?
September 06, 2019, 04:58:12 AM
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
September 04, 2019, 10:02:24 AM
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!
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!
September 04, 2019, 09:09:32 AM
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: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
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.
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
September 04, 2019, 08:56:28 AM
Just an FYI, v1.5q5 still lost connection 'can't connect to any pool'. I lost 45 mins mining time.
September 03, 2019, 10:17:07 PM
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
yupminiZ<150,5,3>[3:1:00:3933]: Selecting GPU#0[0] P104-100
GPU Bus load, reported by GPU-Z, also varies from 7 to 16%, with worst performing GPUs using less bus bandwidth.
we just released a v1.5q3 beta version.
Could you check if there is any improvement for the P104?
Thanks.
Cheers
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
September 03, 2019, 10:12:57 PM
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
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)
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
September 03, 2019, 10:11:12 PM
any way you could add exchangecoin EXCC its 144,5 algo? Please
Hi sharmanovwe'll have a look.
We will see if this is possible for the next release.
Thanks for the suggestion.
Cheers
September 03, 2019, 10:10:29 PM
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,
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
September 03, 2019, 03:43:22 PM
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
yupminiZ<150,5,3>[3:1:00:3933]: Selecting GPU#0[0] P104-100
GPU Bus load, reported by GPU-Z, also varies from 7 to 16%, with worst performing GPUs using less bus bandwidth.
we just released a v1.5q3 beta version.
Could you check if there is any improvement for the P104?
Thanks.
Cheers
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
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
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
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
September 03, 2019, 03:32:44 PM
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
September 02, 2019, 11:04:09 AM
any way you could add exchangecoin EXCC its 144,5 algo? Please
September 02, 2019, 03:37:46 AM
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
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)
September 02, 2019, 01:54:48 AM
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
September 01, 2019, 09:52:14 PM
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
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.
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
September 01, 2019, 09:51:11 PM
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,https://bitcointalksearch.org/topic/claymores-dual-ethereum-amdnvidia-gpu-miner-v150-windowslinux-1433925
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
September 01, 2019, 12:25:07 AM
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
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.
September 01, 2019, 12:09:46 AM
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,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!
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://bitcointalksearch.org/topic/claymores-dual-ethereum-amdnvidia-gpu-miner-v150-windowslinux-1433925
August 31, 2019, 09:58:21 PM
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,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!
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
Jump to: