Yes, this is a working BIOS for MSI RX 480 4GB with Hynix, box code #912-V341-028

It's not the most "modern" timing mod (it's not taking advantage of the latest understanding/decoding of timing straps) but it does give ~28mh
The link is functional, but it has to be copied & pasted.

@Claymore,

I've now been able to replicate the EthMan bug with as few as 3 miner entries, tested on both Win 7 x64 and Win 10 machines.

Freshly generated config file with three local IPs added, only one of which has a running miner. (ETH 9.4)
Leave open for 5-10min, crashes every time. (all miners shown as red/offline)

great, thanks!

Is there anything I can do to assist in tracing the cause?
I've noticed this issue occasionally on past versions, and with the latest release I seem to be able to reliably reproduce it whenever there are multiple offline rigs.

I just did a test with a brand new config file, 10 new miner entries. 5 pointing to unused local IPs, 5 pointing to IPs of active rigs running ETH 9.3 & 9.4

Crashed within minutes, reproduced using the same config on three different machines running a mix of Windows 10 and Win 7 x64

@Claymore

The new version of EthMan seems to hang considerably more frequently when a config includes large numbers of miners and some are offline.
It seems somewhat stable if every single rig it's listening for is online and mining but seems randomly unstable when any rigs are red / offline.

I just tested and it was stable overnight with every rig online.
I then disabled the "this miner is turned off" on four leftover entries from decommissioned rigs, and it crashed within 5-10min.

I saw it happen while looking at the window yesterday... it began while 2 rigs were genuinely offline, then four more functional rigs suddenly became "offline", then every miner went red.
On the plus side... I can actually easily close EthMan when hung now, no more having to kill the process in task manager.

Both WattTool and Afterburner voltage offsets seem to work fine on Gigabyte RX570 Gaming, what cards are you having difficulty with?

Only issue I've seen with WattTool is that it doesn't comprehend the new 500 series memory clock states, it sees one of the intermediate states instead of full load clocks.

I've noticed the same when swapping out a card, I'll change one card and all six end up with different adapter numbers.
Wattool profiles seem to still work if the number is off by only one, but anything more than that and the profile files need to be updated to the new number

From a specs standpoint, the 7950 and RX 460 are in very different leagues.
The 7950 used to be AMD's 2nd highest end gaming card, and has a memory bus 3x as wide and 2x the shader cores.

And of course, that's not ETH. (Epoch #13, Musicoin perhaps?)

LOL, expect closer to 11mh:
http://cryptomining-blog.com/8217-mining-performance-of-gigabyte-windoforce-oc-amd-radeon-rx-460-2gb/

It has about 1/3rd of the horsepower of a RX 480 from a specs standpoint, with just 14 CUs (RX 480 is 32) and a narrow 128bit memory bus

Once again, you must be doing something seriously wrong to kill that many cards in such a short span.
There is no way you received 7 "defective" cards of multiple models.

Hynix memory RX 470s work just fine, most will do ~1900mhz or so without memory errors, the occasional one will handle a bit higher.

If you cannot figure out what you did wrong, you'll probably end up killing the next batch too.
My suspicion would be some issue with power supply and/or risers.

Wait... so you've managed to kill numerous 4GB and 8GB cards in just a few weeks?
Sounds like the problem is with you, not the cards.

My best results with Samsung 4GB ( K4G41325FE ) have been using the 1625mhz strap at 1950-2050mhz but I'm still trying to determine long-term stability for each individual card
stock 1625mhz strap:
1150 / 2000mhz = 28.1mh  (MSI 470 Gaming 4GB)
1150 / 1900mhz = 27.5mh (MSI 470 Armor 4GB)
Using Claymore in Windows, 16.11.5 drivers

I've noticed some odd behavior though... on my initial attempt I was able to gradually raise clocks on one card as high as ~2100mhz (I saw 29.5mh!), but it only seems to work if I raise the clocks while miner is already running and then pause/unpause, the initial miner / DAG loading does not seem stable with these timings at high clocks.

My other test card I seemingly had mining stable up to 2050mhz, only to find that it can't create the DAG at anything above 1965mhz without crashing the system

I've also noticed that the Samsung 4GB equipped cards doesn't seem to report any GPU memory errors in Hwinfo64, even when memory clocks are pushed high enough to cause errors / crashes in Claymore.

My suspicion is this is a result of Claymore v12's boost in VRAM used at higher intensities, and that our timings are too tight to accommodate accesses to the larger chunk of VRAM.
It's possible we may see better results with less aggressive timing mods + higher intensities, I will have to do some experimentation.

Anyone else here notice lots of instability on strap-modded Tahiti cards with Claymore ZEC v12?
Seems like some cards refuse to handle the higher intensities, I have a few cards that are unstable at anything above 2 or 3 intensity.

I'm not sure if it's the timing mods, the undervolts or some odd combination of both.

Just as a suggestion, the bulk of "voltage locked" AMD cards are not truly locked on a hardware level.
As I understand it, some have a BIOS-level restriction that prevents software adjustment, and others use voltage regulator that isn't supported by the usual software.

But... in both cases BIOS editing is usually able to adjust the voltage, which can do wonders for Pitcairn & Tahiti series cards that shipped at 1.25v

This will do it:
https://www.techpowerup.com/forums/threads/vbe7-vbios-editor-for-radeon-hd-7000-series-cards.189089/

This is for a MSI RX 480 Armor 4G OC #912-V341-028 with Hynix memory
https://mega.nz/#!vAs3TDQJ!W2HPI70RY1TO5J65_VRj7iKTIElDv6nIzQb6AeUii3w

Currently getting ~27.9mh running at 1125mhz core 1940mhz memory, undervolted to 950mV
Some will not clock quite that high without memory errors, I would start at 1850mhz and check using hwinfo64 sensors mode to find a sweet spot.

ETH: 0xc2ead463087fa1ac515eb6d6b575362920346bdb

I had a similar issue with a bad batch of MSI 280x fans a few years back.

Apparently the fan hub/bearing includes a gel lubricant, which when run at high speed over an extended span can become liquefied and be forced out of the fans.
I had several rigs with every card partially coated in a very thin layer of the stuff, one even had a slow-motion drip suspended from the bottom edge of the PCB.
Thankfully I'm told the gel is non-conductive, and I only noticed the issues when the fans began to seize up.

MSI should RMA them no sweat, there's just no guarantee they'll send more Furys. My most recent RMA of R9 290s was replaced with 6GB GTX 1060s

Am having issues on several rigs today when mining XMR.


First sign of trouble:


01/05/17-15:07:54 - New job received from xmr-usa.dwarfpool.com:8050
cannot convert blob data
01/05/17-15:07:58 - SHARE FOUND (target 10000) - (GPU 3 of 4)
Share accepted (172 ms)!
01/05/17-15:08:06 - SHARE FOUND (target 10000) - (GPU 1 of 4)
Share rejected (203 ms)!
{"id":4,"jsonrpc":"2.0","error":{"code":-1,"message":"Lowdifficultyshare"}}
01/05/17-15:08:10 - SHARE FOUND (target 10000) - (GPU 2 of 4)
Share rejected (187 ms)!
{"id":4,"jsonrpc":"2.0","error":{"code":-1,"message":"Lowdifficultyshare"}}
01/05/17-15:08:23 - SHARE FOUND (target 10000) - (GPU 0 of 4)
Share rejected (156 ms)!



and then progresses to:

01/05/17-15:09:48 - SHARE FOUND (target 10000) - (GPU 0 of 4)
Share accepted (203 ms)!
DevFee: 01/05/17-15:09:55 - SHARE FOUND (target 10000) - (GPU 0 of 4)
01/05/17-15:10:00 - SHARE FOUND (target 10000) - (GPU 0 of 4)
Share accepted (203 ms)!
01/05/17-15:10:05 - SHARE FOUND (target 10000) - (GPU 0 of 4)
Share rejected (156 ms)!
{"id":4,"jsonrpc":"2.0","error":{"code":-1,"message":"Unauthenticated"}}
01/05/17-15:10:09 - SHARE FOUND (target 10000) - (GPU 3 of 4)
Share rejected (157 ms)!
{"id":4,"jsonrpc":"2.0","error":{"code":-1,"message":"Unauthenticated"}}
01/05/17-15:10:16 - SHARE FOUND (target 10000) - (GPU 3 of 4)
Share rejected (156 ms)!
{"id":4,"jsonrpc":"2.0","error":{"code":-1,"message":"Unauthenticated"}}
01/05/17-15:10:25 - SHARE FOUND (target 10000) - (GPU 0 of 4)
Share rejected (156 ms)!
{"id":4,"jsonrpc":"2.0","error":{"code":-1,"message":"Unauthenticated"}}
01/05/17-15:10:27 - SHARE FOUND (target 10000) - (GPU 0 of 4)
Share rejected (125 ms)!



I have also seen some rigs complain about an IP ban, but it's inconsistent... it's like I'm occasionally banned from just one of the IPs that xmr-usa.dwarfpool.com resolves to, but not the rest?

These rigs are all using Claymore 9.6 & 9.7, and the issue seems to impact just a couple rigs at a time... with the rest of the fleet apparently continuing to mine without issue.

I ran across the weirdest BIOS yesterday...
It's an XFX 280 and has timings for Hynix AFR, BFR and Elpida.... but the timing table is TINY!

Each one has only four timings with transitions at 400, 800, 1250 and 1625

Unsure if the card was AFR or BFR so modded both, getting peaks just over 110 sol

That number is simply used to label each particular set of timings, AFAIK the number used is arbitrary.

Some card BIOSes include timings for multiple types of memory, it allows a GPU manufacturer to switch VRAM used in production batches based on price/availability/etc... without making any other changes.

An Elpida timing could potentially be 00, 01, 02 (or possibly even 03) it depends on how many sets of timings the BIOS has.

Personally, when I 'm hunting for timings in hex I search for 33 20 00 00 00 00 to find all the timings regardless of what numbering scheme they used.

Yup, seems to be issues with -i 2 on some of the older cards, I've noticed issues with both incorrect data and rejected shares (different rigs)

-i 0 and 1 seem to run great