I believe -mvddc is memory controller voltage, not the actual memory voltage which is non-adjustable on these cards.  I run separate values for core and memory controller with no issues on RX580s.

Going back to the 18.9.2 driver allows me to dynamically update using AMDmemTweak again while Claymore 11.9 is running under the newest Win10.  19.6.3 still didn't work.  It took quite a while to crawl back to 18.9.2 to find one that worked.

EDIT:

Well, I spoke too soon.  I was able to do it briefly but then it locked me out again.  I don't know what the solution is other than making sure to modify before running Claymore.  But it sure was nice for a while to be able to bring up the GUI version and modify timings on the fly while Claymore was running to see the effect.

Cloudflare was out this morning for some time and that affected my ability to get to several websites, including Nanopool.  Have you considered that the internet doesn't work 100% of the time?

I think you need -allcoins 1 if you're mining a fork.  Also, there's probably not enough memory for a real ETH DAG and so you probably need to disable the mining fee process which would need to create a large DAG every hour.

Once I got the new Win10 update, I could no longer change the timings on the fly with Claymore running.  Even with the 19.4.3 driver.  I tried all of the recent drivers I could find.

I used to be able to do this but can no longer change on the fly after the Win10 update and a driver update.  I may try to go back to older drivers and see if that changes.  To me, that was the best part about the tool ... changes on the fly to see the effects.

In fact, once I run Claymore, I can't change any values even after I stop Claymore.  I have to reboot to make the values modifiable again.

This is Claymore 11.9, not the newer 14.x stuff that uses this same mechanism to adjust the card timings.  I can see where that might conflict.  But 11.9 was allowing mods during mining previously.

I'm on the new Win10 May update and running Radeon driver 19.5.2.  I'm finding that I can run and apply AMDmemTweak changes prior to running Claymore 11.9.  However, once Claymore is running, changes in AMDmemTweak will not longer apply dynamically.  Occassionaly AMDmemTweak will throw an "application error" dialog box but otherwise continues to run.  I've turned off the new Tamper Control in Defender as well.

I can't run Radeon 19.6.2 because it throws a software error and exits when I attempt to enter the setting page.

A month ago, I had absolutely no issues of any kind running and applying AMDmemTweak settings.  I'm sure it's something in the new windows or newer drivers.

I'm using AMDmemTweak 0.2.3 BTW.

The latest Win10 has a new feature called Tamper Protection.  It seems to prevent writing directly to the card's I2C interfaces even with the proper driver.  That may be the problem.  I found that it would prevent AMDMemTweak from adjusting the values as well.  You can turn it off but I can't recall how.  It gave me the option at one point and I took it.

Might not be your problem, but worth a look.  I've been bouncing around with various versions of the AMD driver as well trying to get around this.  I found that 19.6.2 would crash on my machine when going to the settings page.  I backed off to 19.5.2 and it works ok.  I'm only running Claymore 11.9 though.  Waiting for the 14.x to stabilize.

Would the -gser parameter also help his case in lieu of more virtual memory space?

I thought Radeon VII's were already getting 90MH/s with just a refresh rate tweak.  I could also be wrong, but there are a few users over in the AMDTweakTool thread that have them.  Check there.

I think I am running Ubermix 3.1 but it's been a while.  Your original values for RC and RFC match mine.  At REF 30, I have 1 bad hash in about 24 hours.  On my Hynix cards, I can't run beyond REF 18 without too many bad hashes.

This reminds me of the days when a group of us using ATT6300 PC's (8086 machines) would lower the dram refresh rate from that set in BIOS to gain about 12% in processing speed.  Of course, our CPUs were running at 8MHz so that was a big deal for us.

My Samsung memory is weak, only able to run at 1960 with Ubermix.  I was able to bump to 2000 with your suggestion along with a REF 30 and gained 0.7MHs.  I would definitely have to loosen Column Address Strobe Latency to go higher.

Test mode is the only way to run an unsigned kernel mode driver without it being signed with a cert.  When you do "-driver install" you are installing said driver to allow run-time access to the GPU configuration registers via that driver.

I was on my way to testing v14 but first had to move my driver to 19.4.3.  When I moved, I then restarted v12 just to make sure everything was still working.  It turns out, I lost fan control under 19.4.3 and v12.  So I've reverted my driver and have gone back to v12 for now.  

I'm sure the fan stuff probably works in v14 with the newer driver but I don't have time to fight with it now.  Maybe over the weekend.

EDIT: Re-read posts and see that AMD keeps changing the fan API out from under you.  I'm back on v12 but will make a run at v14 later.  Thanks for the work on dynamic strapping.

Running Claymore 11.9, I moved to Radeon 18.8.1 yesterday and over 24 hours got a large number of incorrect shares on one card.  Rolling back to 18.7.1 and will update this post if it clears up.

Moving back to 18.7.1 seems to have cleared it up.  Could just be my system but if you move to 18.8.1, keep an eye on it.

Solo mining through a pool is the same result as solo mining directly to the network, but with an added fee.  If you solo mine through a pool, you are a pool of 1.  Shares have no meaning in a pool of 1 because they are all your shares.  You either find a block or you don't.  It's perhaps useful to allow you to see that you are, in fact, making progress on doing the work but nothing else.  In that case, I guess you're paying the pool fee of 1% or so for ... something.  If you're solo and you go through a pool, you're letting them use their wallet in the block's coinbase and at that point, they can deduct their fee and then give you the rest I suppose.  Maybe the fee is worth it to show your progress?  I don't know.  If you were mining directly on the network, your address would go into the coinbase of the found block and you wouldn't submit "shares" to the network ... only block solutions.

Only in pool mining does a miner submit shares.


When the DevFee mines, it may mine on a completely different pool for example.  It is disconnected from the work you're doing on your wallet address.  The DevFee probably hits a shared pool while you are off on a dedicated channel or solo. 

Why would there be a "share" submitted when solo mining?  You're not on a pool ... right?  If the DevFee cycle hits the block solution, then that wallet address gets the block reward ... all of it.  Pools allow for rewards to be distributed for percentages of work ... not solo.

Amen.  Claymore 11.8 on these 18.5.2 drivers on the 1709 version of Win10 seems really stable.  Especially in my mixed environment with NVidia cards which has given me some trouble over the past couple of months.

I had a similar problem in a mixed AMD / NVIDIA rig.  It was as if Windows itself was in slow motion.  Clicking on menus took seconds for them to respond, etc.  Yet, it seemed the Claymore window was progressing as usual.

For me, it turned out to be the NVidia driver.  I was running V.390.xx and when I brought it forward to v.397.64 it cleared the problem up ... haven't had it since.  I'm not sure which interim version between those actually solved the problem but I'd rather not go back and look for it.  Just happy to have moved past that.  This is on a Win10pro/64 1709 install.

Turned out ... my boot drive was going bad and when trying to quit the closing of the log files was just too much.  It manifested itself in several ways but one was BSD's of various sorts from the display driver.  Maddening to figure that one out.  New drive ... no issues since.  I was lucky there was enough life left in it to pull off a clone.