Author

Topic: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux) - page 492. (Read 785074 times)

sr. member
Activity: 847
Merit: 383
Tried 2.4 for running 25 hrs straight without any interruption and restart. Good job! Now i can switch to your miner.  Cool


need more feedback brothers for trust to this miner
u are paying around 10% for claymore, make no mistake  is not 1%.

Don't spread BS man.  Claymore makes a great product no need to lie about his stuff.  That's coming from a guy using both.
newbie
Activity: 48
Merit: 0
I've tried the 2.4 on a 11 GPU rig (9xRX580 4Gb 1xRX570 4Gb 1xRX480 8Gb), I got steady 325.xxx Mh/s, it's more consistent than Claymore, with Claymore I get 290-322...
Waiting for the dual mining version...
sr. member
Activity: 756
Merit: 250
Tried 2.4 for running 25 hrs straight without any interruption and restart. Good job! Now i can switch to your miner.  Cool


need more feedback brothers for trust to this miner
newbie
Activity: 14
Merit: 0
Tried 2.4 for running 25 hrs straight without any interruption and restart. Good job! Now i can switch to your miner.  Cool
jr. member
Activity: 20
Merit: 0
today i got message unable to submit share to pool, but my other rig was connected just fine phoenix 2.4 as always. using ethminer eu.1 pool port 14444 , no failovers.

mitrobg -- maybe happend the same time with u and me also? weird.

member
Activity: 413
Merit: 17
The miner didn't switch to the backup pool after one of ethermine's servers dropped. Needed a manual restart:

17555:00:58:07.986: main GPUs: 1: 29.930 MH/s (902/1) 2: 28.957 MH/s (845) 3: 28.905 MH/s (872) 4: 30.118 MH/s (841) 5: 28.908 MH/s (919) 6: 28.902 MH/s (925/1)
17555:00:58:09.584: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

17555:00:58:09.593: eths Eth: Unable to read pool response: An existing connection was forcibly closed by the remote host
17555:00:58:09.593: eths Eth: Reconnecting in 10 seconds...
17555:00:58:15.883: main GPU1: 66C 32%, GPU2: 67C 18%, GPU3: 66C 33%, GPU4: 66C 32%, GPU5: 61C 17%, GPU6: 59C 17%
17555:00:58:17.866: GPU4 Unable to submit share - pool disconnected
17555:00:58:19.596: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444
17555:00:58:19.622: eths Eth: Connected to ethash pool eu1.ethermine.org:4444
17555:00:58:19.622: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_submitLogin","worker":"pmethash","params":["0x40EDA1a5924f22CB5C267cbc13525daf46635672.RX2"]}

17555:00:58:25.334: GPU6 Unable to submit share - pool disconnected
17555:00:58:44.057: main GPU1: 66C 32%, GPU2: 66C 19%, GPU3: 66C 34%, GPU4: 66C 32%, GPU5: 61C 17%, GPU6: 59C 17%
17555:00:59:12.123: main GPU1: 66C 32%, GPU2: 66C 18%, GPU3: 66C 33%, GPU4: 66C 33%, GPU5: 61C 17%, GPU6: 59C 17%
17555:00:59:40.302: main GPU1: 66C 33%, GPU2: 66C 18%, GPU3: 66C 34%, GPU4: 66C 32%, GPU5: 62C 17%, GPU6: 59C 17%
17555:00:59:45.489: GPU1 Unable to submit share - pool disconnected
17555:01:00:08.372: main GPU1: 66C 32%, GPU2: 66C 18%, GPU3: 66C 34%, GPU4: 66C 32%, GPU5: 62C 17%, GPU6: 59C 17%
17555:01:00:14.301: GPU1 Unable to submit share - pool disconnected
17555:01:00:17.404: GPU2 Unable to submit share - pool disconnected
17555:01:00:30.295: GPU5 Unable to submit share - pool disconnected
17555:01:00:35.082: GPU1 Unable to submit share - pool disconnected



About the dual mining - IMO it is no longer worth it because there are ASICs for those coins. If you manage to include another algorithm - I'm sure that you'll get even more users.
sr. member
Activity: 847
Merit: 383
One of the units crashed but did not report again to claymore manager and hash and everything looked correct.  It was just scrolling dev fee disconnected and stopped or something like that.  over and over and over again

Closed it and relaunched and it started to work as normal.

clip of log

17554:19:35:24.587: main DevFee: Disconnected and stopped
17554:19:35:24.790: main DevFee: Disconnected and stopped
17554:19:35:24.937: GPU4 Eth: Incorrect ETH share from GPU4
17554:19:35:24.993: main DevFee: Disconnected and stopped
17554:19:35:25.196: main DevFee: Disconnected and stopped
17554:19:35:25.399: main DevFee: Disconnected and stopped
17554:19:35:25.602: main DevFee: Disconnected and stopped
17554:19:35:25.809: main DevFee: Disconnected and stopped
17554:19:35:26.024: main DevFee: Disconnected and stopped
17554:19:35:26.228: main DevFee: Disconnected and stopped
17554:19:35:26.432: main Eth speed: 200.521 MH/s, shares: 851/1/299, time: 6:30
17554:19:35:26.432: main GPUs: 1: 28.677 MH/s (137/40) 2: 28.679 MH/s (118/40) 3: 28.404 MH/s (121/35) 4: 28.745 MH/s (105/52) 5: 28.678 MH/s (138/39) 6: 28.664 MH/s (113/40) 7: 28.674 MH/s (120/53)
17554:19:35:26.432: main DevFee: Disconnected and stopped
17554:19:35:26.635: main DevFee: Disconnected and stopped
17554:19:35:26.839: main DevFee: Disconnected and stopped
17554:19:35:27.042: main DevFee: Disconnected and stopped
17554:19:35:27.245: main DevFee: Disconnected and stopped
17554:19:35:27.448: main DevFee: Disconnected and stopped
17554:19:35:27.651: main DevFee: Disconnected and stopped
17554:19:35:27.855: main DevFee: Disconnected and stopped
17554:19:35:28.059: main DevFee: Disconnected and stopped
17554:19:35:28.261: main DevFee: Disconnected and stopped
17554:19:35:28.465: main DevFee: Disconnected and stopped
17554:19:35:28.668: main DevFee: Disconnected and stopped
17554:19:35:28.871: main DevFee: Disconnected and stopped
newbie
Activity: 67
Merit: 0
trying version 2.4

so far so good

i just have a question

what those two options change?
-mi  when i use the default 10 i have a constant mhs, when i put 12 i have some up and down so what better?
-gt  seem to not change a lot
sr. member
Activity: 847
Merit: 383
ok loading on 10 units to test =)
full member
Activity: 357
Merit: 101
PhoenixMiner 2.4 is officially released. There are no changes from the release candidate that was released a few days ago so if you are already using 2.4, no need to download and install again.

We now are working on 2.5, which should include a few fixes for the DAG allocation and generation instabilities, and a fix for continuing mining when the miner is unable to connect for more than a few minutes. A per-GPU minimal speed will also be implemented, allowing finer control over GPUs slowing down for some reason.
full member
Activity: 357
Merit: 101
I tested the phoenixminer 2.4 and its showing gpu2 fan error and gpu5? any fix on this?
 Are you using Adrenalin driver 17.12.x? If so, please upgrade to the newest driver, which should fix the problem.

i try 2.4. sometime reported hashes on the pool is not registered. Need to restart miner.. Any solution for this?
 Most probably the problem is with the pool - we have seen such problems some pools, which sometimes do not show the reported hasrate (but accepts shares and shows the effective hashrate normally). If the problem persists, please let us know which pool you are using to try and reproduce the problem.

Yep this is a bad problem.... it just sits there trying to connect to the 2 pools in config and the other 2 in epools and never connects.  If I shut PM down and just restart the app it connects and works fine.  FIX THIS it's a bad problem and with that said back to claymore I go until I can get a confirmation this is repaired.
 Thank you for trying our miner. The first problem (with the "connection attempt aborted" errors) is already fixed in PhoenixMiner 2.4, which is now being officially released. However we will also fix the continuing mining after the connection is being lost for any reason. In such cases the mining will stop after a few minutes and this will be properly reported to the remote manager. We are also adding some DAG switching stability improvements in version 2.5 and we will net you know when it is ready.


sr. member
Activity: 847
Merit: 383
Yep this is a bad problem.... it just sits there trying to connect to the 2 pools in config and the other 2 in epools and never connects.  If I shut PM down and just restart the app it connects and works fine.  FIX THIS it's a bad problem and with that said back to claymore I go until I can get a confirmation this is repaired.
sr. member
Activity: 847
Merit: 383
i swapped about 30 machines to this for a test yesterday and while it seems to be decent there are some quirks. 2 just crash of the 30 on this program but run perfect on claymore.

Mainly and really important for anyone with more than a couple machines is the use of claymores manager.  Yes it shows up but I logged in this morning to see and they showed all up but 2 were in fact down but still showing up.  When I logged into the troubled machines they were trying to connect to pools.  As soon as I shut it off and restarted the miner program NOT the machine it sparked right up.  The problem is that it was reporting to the miner manager that all was good with even the hashrate that was non-existant!  Normally a machine up and not hashing reports 0.00  these were reporting normal hash.

I guess question for dev is, are you going to come up with your own miner manager to fix this or at least fix it to where claymores works correctly in your product?
newbie
Activity: 50
Merit: 0
i try 2.4. sometime reported hashes on the pool is not registered. Need to restart miner.. Any solution for this?
full member
Activity: 357
Merit: 101
this is my log. use v2.4 but still there. and temp.of gpu1 is N/A
  We only managed to reproduce this when using Remote Desktop to control the rig. This is a known problem with Remote Desktop, so you will be better off using something like TightVNC or TeamViewer instead of Remote Desktop.

This happened randomly today on different rigs. Miner restart solves the problem if it doesn't fix itself. Upgraded to 2.4 and so far it seems stable.
The cards shouldn't be loaded when there is no pool connection.
   Thank you for the feedback. This seems to be the DAG allocation/generation instability. We are fixing it as explained in our previous post and the fix should be ready in a few days. As for the other problem (rig continuing to mine without connection), it is noted and we will fix it as well (probably the rig will stop mining after X minutes without connection).

Never used those commands in claymore... . I have about 100W reserve(PSU rating) for (4+4)radeons.
-eres is turned on by default in Claymore and it always allocates DAG buffers big enough for the next two epochs (approx. 15 days). We will implemented -eres first and it will probably solve the problem if it is caused by the DAG allocation instead of DAG generation.

New version 2.4 works great. I have been using your mining software since the beginning of the month. Maybe one of the first  Wink. I have had 0 issues with PheonixMiner and my 6 card rig seems to be about 1mh/s higher per card. Any updates on dual miner progress?
   The kernel for dual decred mining is almost ready but is not completely stable yet. Also the decred stratum support is not fully bug-free, so an alpha version will be ready no sooner than a few weeks.

hello,
are adrenaline drivers same as blockchian drive? or should i use blockchain driver?
   They aren't the same but we haven't found any significant speed difference between the two. So if you are using the blockchain drivers and you are using your GPUs only for mining there is no compelling reason to upgrade yet. If you decide to upgrade anyway, do not install 17.12.x but use 18.1.1 instead, because they reportedly fixed the ADL bus ID bug in 17.12.x. Also, don't forget to check if the Adrenalin drivers are in Compute mode (sometimes they switch back to Graphics upon restart).

jr. member
Activity: 20
Merit: 0
hello,
are adrenaline drivers same as blockchian drive? or should i use blockchain driver?
newbie
Activity: 23
Merit: 0
New version 2.4 works great. I have been using your mining software since the beginning of the month. Maybe one of the first  Wink. I have had 0 issues with PheonixMiner and my 6 card rig seems to be about 1mh/s higher per card. Any updates on dual miner progress?

Thanks!

newbie
Activity: 11
Merit: 0
It seems your fix didnt work out. I had big crash last night (5/24). Its happening pretty much always at night local time (+1 GMT). Maybe some DAG generation issue? This was probably biggest I had. On 2.2b it was just like 1-3 machines thru night and sometimes they recovered. This time it was also with windows error phoneixminer stopped working.( maybe not all of them).

Version 2.4

Is there any way to use maybe another software or somethink to execute bat or sth to close and start again mining? I think ill need to go back to claymore....

   Thank you for the logs - they are really helpful. The good news is that this is a different problem - not the reconnect issue as before (which seems to be fixed as no one reports it anymore) but a DAG generation instability/crash because during DAG generation GPUs draw more significantly power than in normal operation. There are a few ways to fix this and you have probably used them with the Claymore's miner, so we aren't going to invent the wheel and will implement the following options in the next release that is expected in a few days:
 -lidag command-line option to decrease the speed of DAG generation in order to lower the power needed
 -gser command-line option to avoid DAG generation on all GPUs simultaneously, which may strain the PSU(s)
 -eres command-line option to allocated more memory than needed for the current DAG epoch in order to avoid allocating memory on each DAG switch

  As DAGs are always generated on starting the miner and this didn't happen then, most probably the -eres option (which will be enabled by default) and probably -lidag as well should solve the DAG switch instabilities.





Never used those commands in claymore... . I have about 100W reserve(PSU rating) for (4+4)radeons.
member
Activity: 413
Merit: 17
Odd miner crash on one of the rigs, possibly during DAG generation:

17553:05:17:15.915: main Eth: Maximum difficulty of found share: 22.4 TH (!!!)
17553:05:17:15.915: main Eth: Average speed (3 min): 174.516 MH/s
17553:05:17:15.915: main Eth: Effective speed: 169.39 MH/s; at pool: 169.36 MH/s
17553:05:17:15.915: main 
17553:05:17:16.583: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

17553:05:17:16.583: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0xa66e781","0x4adc8c04dca8738f6a7f05d4be7d57406f024877200252e02098a6d835386588"]}

17553:05:17:16.635: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0xa3605d373d79be7107e12b21a2ea4776025a2eb5b2422c93c50aa97d3148d060","0xd5d85ca51867514082660716ef2bedbb55a65250622456390b4a76c4fe98db95","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4b87ed"]}
17553:05:17:16.686: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0xa3605d373d79be7107e12b21a2ea4776025a2eb5b2422c93c50aa97d3148d060","0xd5d85ca51867514082660716ef2bedbb55a65250622456390b4a76c4fe98db95","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4b87ed"]}
17553:05:17:16.686: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
17553:05:17:21.102: main Eth speed: 174.530 MH/s, shares: 5015/1/0, time: 32:54
17553:05:17:21.102: main GPUs: 1: 29.926 MH/s (822) 2: 28.950 MH/s (812) 3: 28.896 MH/s (847) 4: 28.961 MH/s (873) 5: 28.903 MH/s (844) 6: 28.894 MH/s (818)
17553:05:17:24.918: GPU3 Eth: GPU3: ETH share found!
17553:05:17:24.918: eths Eth: Send: {"id":4,"jsonrpc":"2.0","method":"eth_submitWork","params":["0xbf9db8226ae1f459","0xa3605d373d79be7107e12b21a2ea4776025a2eb5b2422c93c50aa97d3148d060","0x7c5b0c7e7407368eedfb61a4c61f401d6f6876be8a2f83ae485496ab88e6e895"]}

17553:05:17:24.918: eths Eth: Share actual difficulty: 6415 MH
17553:05:17:24.974: eths Eth: Received: {"id":4,"jsonrpc":"2.0","result":true}
17553:05:17:24.974: eths Eth: Share accepted in 56 ms
17553:05:17:25.681: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x67e64195f2b5bc6a6752c83288848e066aa5cd2f389ef6d4f2f8e481f67d992f","0xd5d85ca51867514082660716ef2bedbb55a65250622456390b4a76c4fe98db95","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4b87ee"]}
17553:05:17:25.681: eths Eth: New job #67e64195 from eu1.ethermine.org:4444; diff: 4000MH
17553:05:17:26.175: main Eth speed: 175.198 MH/s, shares: 5016/1/0, time: 32:54
17553:05:17:26.175: main GPUs: 1: 29.929 MH/s (822) 2: 28.962 MH/s (812) 3: 29.976 MH/s (848) 4: 28.961 MH/s (873) 5: 28.912 MH/s (844) 6: 28.458 MH/s (818)
17553:05:17:26.834: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x6022e0b455a696b6186a8e74d196c67561898451ac2971764bbd7cdf789a05d8","0xd5d85ca51867514082660716ef2bedbb55a65250622456390b4a76c4fe98db95","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4b87ee"]}
17553:05:17:26.834: eths Eth: New job #6022e0b4 from eu1.ethermine.org:4444; diff: 4000MH
17553:05:17:28.922: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x2541e8c9ec1edab496dedf5abab0e319fe97b61ed38f9157642117d1ab531440","0xd5d85ca51867514082660716ef2bedbb55a65250622456390b4a76c4fe98db95","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4b87ef"]}
17553:05:17:28.922: eths Eth: New job #2541e8c9 from eu1.ethermine.org:4444; diff: 4000MH
17553:05:17:31.356: main Eth speed: 172.836 MH/s, shares: 5016/1/0, time: 32:54
17553:05:17:31.356: main GPUs: 1: 29.931 MH/s (822) 2: 28.956 MH/s (812) 3: 27.201 MH/s (848) 4: 28.951 MH/s (873) 5: 28.901 MH/s (844) 6: 28.897 MH/s (818)
17553:05:17:33.276: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xac9fac191904a9c93f43051b963c25a403565b2526b0149ab66c7f67c87a2e59","0x51e74ac038c9e3e66658ef25c159102238ecfd6ec09db5abc675fa9207530dad","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x4b87f0"]}
17553:05:17:33.277: eths Eth: New job #ac9fac19 from eu1.ethermine.org:4444; diff: 4000MH
17553:05:17:33.322: GPU4 GPU4: Starting up...
17553:05:17:33.322: GPU4 Eth: Generating light cache for epoch #165
17553:05:17:33.463: GPU3 GPU3: Starting up...
17553:05:17:33.623: GPU1 GPU1: Starting up...
17553:05:17:33.742: GPU6 GPU6: Starting up...
17553:05:17:33.796: GPU5 GPU5: Starting up...
17553:05:17:33.818: GPU2 GPU2: Starting up...
17553:05:17:42.632: main Eth speed: 178.198 MH/s, shares: 5016/1/0, time: 32:54
17553:05:17:42.632: main GPUs: 1: 29.932 MH/s (822) 2: 28.968 MH/s (812) 3: 32.525 MH/s (848) 4: 28.957 MH/s (873) 5: 28.916 MH/s (844) 6: 28.901 MH/s (818)
17553:05:17:42.632: main GPU1: 60C 32%, GPU2: 57C 18%, GPU3: 60C 34%, GPU4: 60C 32%, GPU5: 58C 17%, GPU6: 52C 17%



Ethermine disconnect for a hour or so on one of the rigs. Internet was stable, other rigs were fine, ethermine didn't register the rig being offline:

17553:02:12:11.072: main Eth: Effective speed: 169.74 MH/s; at pool: 169.70 MH/s
17553:02:12:11.072: main 
17553:02:12:11.072: eths Eth: Reconnecting in 10 seconds...
17553:02:12:21.075: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444
17553:02:12:22.578: main GPU1: 66C 33%, GPU2: 67C 19%, GPU3: 66C 36%, GPU4: 66C 33%, GPU5: 63C 17%, GPU6: 61C 17%
17553:02:12:24.326: unkn Eth: Connection attempt aborted
17553:02:12:24.326: unkn Eth: Reconnecting in 15 seconds...
17553:02:12:36.938: GPU2 Unable to submit share - pool disconnected
17553:02:12:39.329: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444
17553:02:12:42.578: unkn Eth: Connection attempt aborted
17553:02:12:42.578: unkn Eth: Reconnecting in 20 seconds...
17553:02:12:50.579: main GPU1: 66C 33%, GPU2: 66C 19%, GPU3: 66C 36%, GPU4: 66C 33%, GPU5: 63C 17%, GPU6: 60C 17%
17553:02:13:02.581: unkn Eth: Connecting to ethash pool eu1.ethermine.org:4444
17553:02:13:05.832: unkn Eth: Connection attempt aborted
17553:02:13:05.832: unkn Eth: Giving up after 3 retries, switching to next pool
17553:02:13:05.832: unkn Eth: Reconnecting in 7 seconds...
17553:02:13:12.835: unkn Eth: Connecting to ethash pool us1.ethermine.org:4444
17553:02:13:16.089: unkn Eth: Connection attempt aborted
17553:02:13:16.089: unkn Eth: Reconnecting in 10 seconds...
17553:02:13:18.697: main GPU1: 66C 33%, GPU2: 66C 19%, GPU3: 66C 36%, GPU4: 66C 33%, GPU5: 64C 17%, GPU6: 60C 17%
17553:02:13:26.092: unkn Eth: Connecting to ethash pool us1.ethermine.org:4444
17553:02:13:29.343: unkn Eth: Connection attempt aborted
17553:02:13:29.343: unkn Eth: Reconnecting in 15 seconds...
17553:02:13:33.357: GPU3 Unable to submit share - pool disconnected
17553:02:13:44.345: unkn Eth: Connecting to ethash pool us1.ethermine.org:4444
17553:02:13:46.904: main GPU1: 66C 33%, GPU2: 67C 19%, GPU3: 66C 36%, GPU4: 66C 33%, GPU5: 64C 17%, GPU6: 60C 17%
17553:02:13:47.071: GPU4 Unable to submit share - pool disconnected
17553:02:13:47.595: unkn Eth: Connection attempt aborted
17553:02:13:47.595: unkn Eth: Reconnecting in 20 seconds...
17553:02:13:51.728: GPU1 Unable to submit share - pool disconnected




This happened randomly today on different rigs. Miner restart solves the problem if it doesn't fix itself. Upgraded to 2.4 and so far it seems stable.
The cards shouldn't be loaded when there is no pool connection.
full member
Activity: 357
Merit: 101
this is my log. use v2.4 but still there. and temp.of gpu1 is N/A
  Thank you for the log. We will try to reproduce the problem and fix it for the next release (later this week).

It seems your fix didnt work out. I had big crash last night (5/24). Its happening pretty much always at night local time (+1 GMT). Maybe some DAG generation issue? This was probably biggest I had. On 2.2b it was just like 1-3 machines thru night and sometimes they recovered. This time it was also with windows error phoneixminer stopped working.( maybe not all of them).

Version 2.4

Is there any way to use maybe another software or somethink to execute bat or sth to close and start again mining? I think ill need to go back to claymore....
   Thank you for the logs - they are really helpful. The good news is that this is a different problem - not the reconnect issue as before (which seems to be fixed as no one reports it anymore) but a DAG generation instability/crash because during DAG generation GPUs draw more significantly power than in normal operation. There are a few ways to fix this and you have probably used them with the Claymore's miner, so we aren't going to invent the wheel and will implement the following options in the next release that is expected in a few days:
 -lidag command-line option to decrease the speed of DAG generation in order to lower the power needed
 -gser command-line option to avoid DAG generation on all GPUs simultaneously, which may strain the PSU(s)
 -eres command-line option to allocated more memory than needed for the current DAG epoch in order to avoid allocating memory on each DAG switch

  As DAGs are always generated on starting the miner and this didn't happen then, most probably the -eres option (which will be enabled by default) and probably -lidag as well should solve the DAG switch instabilities.



Jump to: