B кaкиx eдиницax знaчeния пapaмeтpa? --maxnosharesent value(if no share is sent to the pool for x time, restarts miner. def. is 15 min)
Чтo нaпиcaть в бaтникe, чтoбы интepвaл пepeзaгpyзки cтaл paвным 60мин?
Пиши по английски, тут русскоговорящих - раз-два и обчелся. Англоязычный форум же.
|
|
|
Author, how to force one of GPU use one thread? I tried --cn_config 14, --cn_config 14+0 but these variants causes miner to close after run. I need that to free some GPU power from one of gpu from mining to other purposes...
Ah, I remember you have one gpu with monitor(?). Sorry to say we don’t include a single-threaded mode since we didn’t anticipate anyone needing it, it’s rather just a risk that people enable it and you get extra support questions . But, we can probably introduce x+0 meaning that we disable the second thread. I’ll check it and schedule it for a future release. Thanks! I'll wait this. How to lower intensity? Just lower numbers in --cn_config?
|
|
|
Author, how to force one of GPU use one thread? I tried --cn_config 14, --cn_config 14+0 but these variants causes miner to close after run. I need that to free some GPU power from one of gpu from mining to other purposes...
|
|
|
what about intensivity for moneror for 570 8gb? default 71 its ok? 890hs
Try to set it 104, 112, 118. Your card can more. 71 - is not optimal for 8Gb card. I'm use TRM cause it gives +50 h/s on one of my RX 588 cards. You can try it too. what is trm? TeamRed miner
|
|
|
what about intensivity for moneror for 570 8gb? default 71 its ok? 890hs
Try to set it 104, 112, 118. Your card can more. 71 - is not optimal for 8Gb card. I'm use TRM cause it gives +50 h/s on one of my RX 588 cards. You can try it too.
|
|
|
What about optimal settings for Polaris 8Gb cards? On my RX 588 - one of them best settings is 8+8, on other 14+14.
|
|
|
On nicehash --no_cpu_check didn't help too. For me with this option rejects became more... Disable it. Tried other miners. Speed on all slower, also exists rejects "job not found". Pool-side speed on TR miner is best! Waiting updates!
|
|
|
Windows version?
We will release it soon. I will be waiting for this version. Thanks. Me too.
|
|
|
Confirm, nicehash cnr mining - many rejected shares - job not found. And "Dev pool connection was closed by remote side. Mining will proceed at reduced rate etc etc"
Hey guys! Sorry about all the mess with dev pool, there are some issues outside of our control that we are addressing, should hopefully be resolved today. However, I do believe you all see a reconnect within 30 secs or so, so the "reduced rate" period should really be minimal. Let me know if you are experiencing longer disconnected periods than 30-60 secs. What about high amount of rejects due to "job not found" on nicehash? The one big difference is that open source miners have excellent cpu code for the algo, borrowed from their cpu miner. For rigs with slow celerons, we will add significant latency with our more naive on-cpu verification. We need to implement automatic generation of x86 machine code for the random ops in CN/r, quite annoying crap to spend time on, but we don’t really have a choice it seems. Fix for now: if your rig(s) are running without any hw errors, try running with —no_cpu_check. This will disable our check and let the pool run the check instead. Will be fine on most pools and if you don’t oc so much that you get invalid shares that you flood the pool with . I didn't understand all of this. But I must notice that on other miners not so much rejected shares on nicehash. Speed on cnr on this miners is slower but lower rejected shares and lower fee can do the profit higher... Thanks for option --no_cpu_check. I'll try it. But I use overclocked cards, so this may not help... Anyway I'll try it. We will speed up our cpu code properly, we just didn't have the time for it with this release. Overclocked cards are not bad in itself as long as they aren't pushed so hard they generate hw errs. Do you see any counts in the "hw" category when the hashrate stats are displayed? Very rare. About 1-2 error on 24 hours on 1 of cards.
|
|
|
Confirm, nicehash cnr mining - many rejected shares - job not found. And "Dev pool connection was closed by remote side. Mining will proceed at reduced rate etc etc"
Hey guys! Sorry about all the mess with dev pool, there are some issues outside of our control that we are addressing, should hopefully be resolved today. However, I do believe you all see a reconnect within 30 secs or so, so the "reduced rate" period should really be minimal. Let me know if you are experiencing longer disconnected periods than 30-60 secs. What about high amount of rejects due to "job not found" on nicehash? The one big difference is that open source miners have excellent cpu code for the algo, borrowed from their cpu miner. For rigs with slow celerons, we will add significant latency with our more naive on-cpu verification. We need to implement automatic generation of x86 machine code for the random ops in CN/r, quite annoying crap to spend time on, but we don’t really have a choice it seems. Fix for now: if your rig(s) are running without any hw errors, try running with —no_cpu_check. This will disable our check and let the pool run the check instead. Will be fine on most pools and if you don’t oc so much that you get invalid shares that you flood the pool with . I didn't understand all of this. But I must notice that on other miners not so much rejected shares on nicehash. Speed on cnr on this miners is slower but lower rejected shares and lower fee can do the profit higher... Thanks for option --no_cpu_check. I'll try it. But I use overclocked cards, so this may not help... Anyway I'll try it.
|
|
|
Confirm, nicehash cnr mining - many rejected shares - job not found. And "Dev pool connection was closed by remote side. Mining will proceed at reduced rate etc etc"
Hey guys! Sorry about all the mess with dev pool, there are some issues outside of our control that we are addressing, should hopefully be resolved today. However, I do believe you all see a reconnect within 30 secs or so, so the "reduced rate" period should really be minimal. Let me know if you are experiencing longer disconnected periods than 30-60 secs. What about high amount of rejects due to "job not found" on nicehash?
|
|
|
Can't reach TR miner speed on SRB cnr algo on 2nd of my RX 580 8G. On other card speed is the same. But on Sapphire TR miner gives 1040 h/s on cnr, SRB max - 1001 h/s. I think that thread_delay can help. I tried some changing in it, but not successful...
|
|
|
Confirm, nicehash cnr mining - many rejected shares - job not found. And "Dev pool connection was closed by remote side. Mining will proceed at reduced rate etc etc"
|
|
|
Thanks Can you please show me how it done? I tried but it doesn't connect to the stratum servers.
Add --tls 0 to command line.
|
|
|
Can lolMiner mine with NiceHash stratum servers?
Yes, I mined beam on nicehash via this miner.
|
|
|
Will you add asm version for windows?
|
|
|
Can't wait for the fork and the new miner... can't go back to mining XMR with the others... wont! hehe.
Right! This miner not for XMR coins. It's for lyra2rev3, lyra2z, phi2. Huh? Of course it's for XMR. When released, it was (still is?) the most efficient cnv2 miner available. And from what's been stated here - they are working on cnv4 to hopefully be ready by the fork. I'm guessing it's a misunderstanding - right now we're discussing in the compute algo thread for TRM. When we added CNv2/v8, we decided to start a separate topic for TRM/CN, otherwise the (much fewer) questions around lyra2z and phi2 would have been really hard to track in the midst of all the CN discussions. So, I'm guessing UnclWish thinks it's two separate miners. As you've pointed out though, it's a single unified release supporting all algos in one binary. Cheers, K Yes, I know that it's one miner. But different threads )))
|
|
|
Can't wait for the fork and the new miner... can't go back to mining XMR with the others... wont! hehe.
Right! This miner not for XMR coins. It's for lyra2rev3, lyra2z, phi2.
|
|
|
|