My fury card wont start mining on version higher than 10. Last 1 working is Claymore's ZCash AMD GPU Miner v10.0 Beta - Catalyst 15.12-16.x
On newer I get 0 H/s and after some time driver crashes and miner tries to start again till same happens again.
Then you are doing something wrong.. I am running 5 fury's and 2 fury x's running version 12.6 with 16.3.2 drivers
My experience is that compared to other Claymore miners, this ZEC one seems to be least stable in current version.
Not simply complaining; I am grateful to have good miner, and happy to pay for it with Dev Fee, because = stability.
Running 8 gigabyte RX580's, Win10, various drivers; I have mined 30 days solid using latest Claymore Dual, mining for ETH only, with zero problems. Fans are well controlled, as is temp. No reboots. Using miningpoolhub with no problems.
With this ZEC miner on same hardware, the miner does not last more than 8-9 hours without reboot due to miner hang. While mining, it gets 2.3MH/s at flypool on average.
Have not tried debug log level yet.. Logs do say: "watchdog - thread 31, hb time 0" then the reboot. This does not show in logs every time, for every reboot.
Have reduced intensity from 6 to 5, no difference in reboots, but can see the difference in reported hashrates at pool.
Have tweaked gpu and mem clocks to be conservative and as even as possible; and also tried larger ranges between each card. None of cards are overclocked, all are underclocked or zero clock changes using Wattman. (I burn the values into each VBIOS.)
Other weird things I noticed, maybe have no meaning and just flake;
Using the -mport option in any form, it caused immediate loss of fan control to the miner (eg -fanmin 50 no longer had any effect).
Sometimes the reboot seemed to come after Dev Fee mining sees a stale share.
Sometimes reboot seemed to come after >5 stale shares.
Checking hashrates and % invalid at pool, the qty of invalid shares is to good shares is 0.02 - 0.03% - so it is not like crazy overclocked, with high number of rejects; I guess qty of invalid shares does *not* seem tied to reboot.
