Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v15.0 (Windows/Linux)

[iSuX]

@Claymore

Saw this today in my log file:

08:38:29:239   4304   checked ETH share on CPU, spent 4ms
08:38:48:975   43b8   checked ETH share on CPU, spent 3ms
08:39:09:055   43c0   checked ETH share on CPU, spent 3ms

Don`t think that is normal.

Nothing to worry about, this is totally normal.
Look back through your old logs, (use grep for example), and you'll see it's a regular event in the log.
Mr Claymore would be the only person who can explain why he's programmed this, but no doubt there is a logical reason.

Side note: Generally, (assuming the programmer is not a total moron), log entries will have some prefix, or suffix, "warning", "error", "OK", "good" etc etc, which makes life easier when searching logs for problem events, or notable events you might like to check on.

Conversely, if you don't see such annotations, and the log entry is not self explanatory, you can generally ignore such entries. (as in they are not things you need to worry about).

And No, it's not a virus either.

Thanks for your reply iSuX. I was just wondering why is there CPU share

Thanks iSuX.  I checked old logs and see that this event is in all of them.  I never noticed it before.  I was experiencing system instability yesterday, checked the log, saw this event, assumed it was a virus, ran virus scanner, removed viruses, and system went back to stable.  IDK how I got a virus, but thanks for pointing out that it's not related to the cpu share.

Like Snake, I would appreciate an explanation from Claymore for why the program is checking for eth shares on the CPU.  Maybe it's checking for a virus mining on the cpu?

@androstan1234
Bummer man, what virus was it you had?

[androstan1234]

@Claymore

Saw this today in my log file:

08:38:29:239   4304   checked ETH share on CPU, spent 4ms
08:38:48:975   43b8   checked ETH share on CPU, spent 3ms
08:39:09:055   43c0   checked ETH share on CPU, spent 3ms

Don`t think that is normal.

Nothing to worry about, this is totally normal.
Look back through your old logs, (use grep for example), and you'll see it's a regular event in the log.
Mr Claymore would be the only person who can explain why he's programmed this, but no doubt there is a logical reason.

Side note: Generally, (assuming the programmer is not a total moron), log entries will have some prefix, or suffix, "warning", "error", "OK", "good" etc etc, which makes life easier when searching logs for problem events, or notable events you might like to check on.

Conversely, if you don't see such annotations, and the log entry is not self explanatory, you can generally ignore such entries. (as in they are not things you need to worry about).

And No, it's not a virus either.

Thanks for your reply iSuX. I was just wondering why is there CPU share

Thanks iSuX.  I checked old logs and see that this event is in all of them.  I never noticed it before.  I was experiencing system instability yesterday, checked the log, saw this event, assumed it was a virus, ran virus scanner, removed viruses, and system went back to stable.  IDK how I got a virus, but thanks for pointing out that it's not related to the cpu share.

Like Snake, I would appreciate an explanation from Claymore for why the program is checking for eth shares on the CPU.  Maybe it's checking for a virus mining on the cpu?

@androstan1234
Bummer man, what virus was it you had?

It was called coin-bitminer or something like that.  First time this has happened to me in almost 10 months of mining.  IDK how it happened.  Maybe related to windows 1803 update since that's the only thing that's changed.  But I updated both of my rigs, and both use the same router (really a 4G LTE hotspot).  Only one caught the virus.

On the subject of Virus, sigh, if you take 2 milliseconds to think about that, and you can probably assume a virus is unlikely to have your best intentions to heart, ergo, it's going to do something you'd rather not have happen, well, it's hardly likely to have the moronic goal of hacking the claymore binary to make it mine with the CPU or advertise itself, by writing it's own log entries.
Hahahaha.

I mean, people make stupid viruses, and stupid, lazy, and/or inattentive people fall for them.  I figured, maybe someone found a way to force claymore software to mine on cpu and send shares to their wallet, thinking that a tiny amount of mining on a cpu would go unnoticed.  A side effect could be that the claymore software dutifully reports and logs whatever is going on.  If enough rigs get infected, all those tiny amounts could add up to a decent chunk of free money. 

[crypsy]

EthDcrMiner64.exe -epool etc-eu1.nanopool.org:19999 -ewal 0xa572dd9dcbcbe537e65c740f27cbd6de5b42a514/3 -epsw x -dpool stratum+tcp://mine.nlpool.nl:5133 -dwal DGr37NMCTSEXZqqPk7gHhikCCd3Ar2Py2b -dpsw c=XVG -dcoin blake2s -allpools 1

hi , i have 100% rejected from pool for xvg
what I am doing wrong

[argai666]

EthDcrMiner64.exe -epool etc-eu1.nanopool.org:19999 -ewal 0xa572dd9dcbcbe537e65c740f27cbd6de5b42a514/3 -epsw x -dpool stratum+tcp://mine.nlpool.nl:5133 -dwal DGr37NMCTSEXZqqPk7gHhikCCd3Ar2Py2b -dpsw c=XVG -dcoin blake2s -allpools 1

hi , i have 100% rejected from pool for xvg
what I am doing wrong

Your port number is wrong. You should use "5766" for blake2s.

[argai666]

@Claymore

Has anyone requested the ability to do dynamic altcoin mining using DPOOLS.TXT.  XVG Has recently been having problems and I was wondering if its possible to mine a different altcoin if listed in DPOOLS.TXT during failover instead of having to manually change the config file and dpools text when I want to shift.

Just thinking about it, I know a few things would need to change but I think it would be a useful feature.  Failover from XVG pool to DCR pool or KEECCAK.

You can use dpools.txt for only coins between same algo. You can not switch algo from blake2s to keccak using dpools.txt

[ganzocrypt]

I am trying to dual mine ETH and SmartCash and cannot find a stable clock settings for my RX 580 8GB.

Any suggestions for core and memory clocks, also dcri and ethi intensity?

thx

[mijnerke]

Built a new rig and my hashrate is down...

Old rig:
MB: ASROCK H81 Pro BTC 2.0
CPU: Intel Pentium G3260 (3.3GHz)
RAM: 8GB - 1333MHz
6GPU

New rig:
MB: Asus B250 Mining Expert
CPU: Intel Celeron G3930 (2,9Ghz)
RAM: 8GB - 2400MHz
updated Bios + Chipset to latest version
9GPU

Dual mining ETH+XVG with Claymore 11.7
Both times Radeon drivers 18.3.1, all compute.
4 of my cards that used to mine ETH at 30Mh/s and now do only 28,3 in my new rig... Those cards are on the same PSU I used in the old rig.

OC/UV used to be 1130 / 2035 / 890 / 890
Tried pushing them to 1130 / 2100 / 880 / 880, but I get minimal gain and seem to have touched the ceiling as I start getting invalid shares and have to get back to safer levels.

This might seem silly, but is it possible I have to flash the BIOS of the GPUs again as the configuration is different? Latest Windows10, so problems with ATIFlash to check... :-(

Thanks for any help

Hey there
"Latest version" is not very informative, such things have numbers for good reason.
Now, that said, there isn't enough data here for a differential analysis, nor any explanation as to why you are thinking, OC or BIOS as candidates.

Assuming you didn't change either of those (OC/Bios) when you migrated your GPUs, from old rig to new rig, (did you?, as you mention 6 GPUs in old rig, and 9 in the new rig), so are 6 of those GPUs moved from old to new rig, and now seem to be hashing slower?

What make/model GPU?

Also, what is far more relevant here is, new motherboard, new ram, new cpu, new OS, new install of everything, and assuming you didn't change BIOS or Claymore config, I'd strongly suggest investigating all the former, before turning the spotlight on the latter.

Some things to consider.

What OS version on both rigs?
IME Win10 Home version out performs Pro in almost every respect, gaming or mining. For one, it's loading a LOT less MS-crap that most people don't need. (If you're not joining a domain, you probably don't need Pro). The number of services is nearly double on Pro, and again, probably you don't need any of the pro stuff for mining.
Mining and stability go hand in hand, and keeping the OS as lean as possible, updates disabled, (set all NICs to metered connection), and manually control/manage how/when you plan on updating, (if at all).

FYI, I also have one rig on the B250ME, and have no issues with different hash rates given same GPU/driver/claymore ver. (I also moved GPUs to that rig, and from it, as I was able to consolidate same make/model/ cards on it) (mixed mem type still, and no issues).
This has been so since day 1 with the B250.
Where the B250 did become a pig, was getting it stable with the 12th GPU, and worse still with the 13th.
That said, spot check, clocking through 75 hours, (claymore 11.7, Win10-64Bit-Radeon-Software-Adrenalin-Edition-18.3.4-March23, Win10Pro 10.0.14393) which is not a record, but I had to reboot last Sat), but the B250 is running well these last 4~5 weeks.
(13x RX580) Sapphire, mix of Hynix/Samsung/Micron2, all on custom BIOS, all hashing >32.

But as you asked, I HAVE seen some issues with ATIWinflash.exe, I've certainly taken some shortcuts, and regretted it. If nothing else, shortcuts add an element of doubt when analysing issues later on, and in some situations, you're unable to quantify those, (doubt remains).

When working with networked systems, by "networked" I mean, multiple computers, (gpus), in a single entity, it's paramount to be systematic, anal always helps :-)

Some tips.
Note the serial numbers of your GPUs, backup the BIOS before you do anything, (use the serial number in the bios file names).
Start off with stock BIOS, (for some days), so you establish a reasonable baseline of data.
GATHER data, write it down. What is "normal" for each etc
Make sure you know which GPU number (in Claymore, in GPU-z, in Radeon-settings), is which, and that way, you know what you are changing, (and can revert), and most important of all, DIFFERENTIATE when you see issues.

I've seen stock BIOS on RX580s, as low as 18MH/s and typically no higher than 29MH/s.

If you mod the BIOS, work on only ONE GPU at a time, version your BIOS edits, (CardMakeModel_SerialNumber_Ver) or something to that affect.
Key point is, make SURE it's clearly identifiable.

Get yourself a METHOD, you are going to end up managing and maintaining a complex system, there are a LOT of variables, so with a standard method, you can at least hope to rule out all the dumb human elements.

Easier said than done, and one should consider "method" a work in progress, refine that as you go along, and maintaining rigs DOES get easier with experience, and systematic analysis.

One thing about fine tuning BIOs: Initially I was struggling to break 30MH/s and made some mistakes,  identified dead ends, had some cards that were real pigs, but actually turned out far better than I expected, even on more than one occasion considered returning.

Try to use all the same make/model/mem-type of card if you plan on a small operation, (<10 GPUs).
I don't say this to cherry pick, or exclude any vendor, but simply because with a small number of cards, it's very hard to know what ""normal" is for them. If you have only 1x Asus RX580, how do you know if it's good/bad/ugly? If you have 2 or more, you can at least hope to make some comparisons.

Also, don't believe everything you read online, (and feel free to ignore me :-) but MAN I read a lot of utter RUBBISH online. In fact, finding the accurate data is the toughest challenge.

One example, that still puzzles me, (note: puzzles me, not saying it's rubbish), is how many people rave about Samsung memory. In my experience, Samsung has been the best out-of-the-box GDDR5, but also the toughest to fine tune. In fact, I'd suggest it's not even worth trying memory strap edits with it.
Drop the power consumption & core clock, up the memory to 2250, and you should be seeing 32.5, and stable. I wasted a lot of time trying to better that, only because I didn't see a big jump, and due to hype, assumed Samsung was the fastest.
By the time I got my hands on my 2 and only Samsung GPUs, I had Micron running super stable at 32.6, up from 29~30 stock, and (mistakenly) figured I could see similar gains with Samsung.

My present conclusion is, Samsung mem is already pretty tightly dialled in, so as an out of the box card, it's certainly the best I have seen, but it certainly is not the top performer in my rigs.

Some notes on BIOS editing.
Make sure you have a versioned stock bios file saved.
Use THAT file for editing. (Do not use BIOS from the net).
Depending on the card and editor, it's highly likely there are other bios elements that are not displayed or editable in the bios editor. Who knows what you change if you flash some random BIOS from the net.
Make sure you have only a single card connected when you flash.
(For SURE, I have done a enmasse deploy to 3 GPUs on multiple occasions, and in recent weeks identified that as a 100% confirmed issue). 2 different rigs, 1~2 cards started to show got incorrect share, after some hours.
What was weird was, those were all cards that were mass-flashed.
What solved that?

Several things.

Shut down rig, bleed down power, remove all but 1 GPU (usb cable), boot up, flash that one card, (I used the same BIOS ver for that same card as last flash), do NOT click ok to the "you must reboot message", but actually shut down, and bleed down the power.
I have a suspicion the dual BIOs cards are capable of holding the BIOS in DRAM and not actually booting to the newly flashed BIOS.
Sure, that will depend on the architecture of the card, but BIOS is typically EERAM, or some similar flash ram type chip.
The card is NOT going to use this (new program), unless several things happen.
A flag/trip is set, (by the flash app), to reload BIOS, (this seems to fail sometimes with Winflash), but for sure, what will force the card to load the new BIOS on next boot, is removal of power, (bleed-down), as this clears the DRAM, and leave the card no choice but to load from EERAM.

Did you notice how slow it is to program BIOS? Those are usually 256 or 512 KB chips. That is KB, KB, nothing these days, yet flashing takes nearly 1 minute for 512 chips. Sure the write speed is slower, but even the verify is slow, and this is because the eeram is not intended to be fast, or used much, (written to), but is depended on to safely store data, without any powered backup.
What typically happens is, as soon as power comes up, the dram content is crc checked with eeram, if ok, card boots, if not, it loads from eeram. As this happens at power on, before os init, that causes no delay in booting. What the winflash does is cause change in crc, and that SHOULD trigger the card to load the bios from eeram on init, but this has certainly failed for me.

I saw no change in card performance after flashing. Stopped claymore, opened winflash, saved BIOS, and sure enough it WAS new, so flash was ok. I shut down, bled-down power, rebooted, and THEN I saw the improvement I was expecting.

My point is, that winflash is only able to read the bios from the eeram, NOT from dram.

Basically you can think of it much like your computer, eeram=hdd and dram=system memory.
This architecture is not so by accident.

The purest will also say you should not use winflash, but rather boot to a very light os, (Dos), and flash from there. This is actually very good advice, but I decided I'd use that as the fall back, and at least start out with WinFlash, as it IS vendor provided after all.


But for sure, it has it's use case, and multiple flashing is a time-saver I've decided is not worth the gain.

But at the same time, I've yet to see those issues insurmountable.

OK, last work on OC.
OC is pushing your luck, if you see issues, remember, you are pushing your luck.
As for the silicone lottery, at least with Sapphire cards, having built rigs for a few people now, I've only had 1 card out of 30 something, that was clearly a dud.
BUT the only way I can say that with certainly is because I documented all the 30+ other cards, (same make/model/memory), and no matter what I did to that one card, it was not stable with any oc at all.
Is that the silicone lottery? I don't think so, I think it was simply a QC issue.
I could be wrong, maybe someone with 100+ cards, data, and experience can chime in here.



OK< last thing.

Did you try setting the dcri?

New rig has 9 GPUs, cmiiw.

DCRI will be different for sure.
Disable dual mining for a start, (pointless, no profit unless you have free power, and even then dubious imho).
Try the "z" key during solo mining, and let claymore find the optimum.
If those numbers are very different from your dcri value, (>2) then I'd suggest at least picking the mean for your config file.

What happened to your hash rate after "z"?

Side note, and no disrespect to Mr Claymore, but usually I find a better dcri value, by using the -+ keys, and set same for all gpu.
But for sure, the z key is a nice feature and great tool to get you 95% optimised and quickly.

Also, set -y 1 check your console during init and make sure you see both lines below.
 
All AMD cards use Compute Mode already
CrossFire is disabled already

 
Otherwise, open admin console, start your batch file as usual, wait for the "all cards now use computer, please reboot"
Reboot, and run claymore as normal, (no need for admin).

THIS IS THE BEST FEATURE from Claymore of late, if you have more than 5GPU, otherwise it's hours of lame AMD-settings, and reboots, to configure each GPU.

Finally, if still no luck, post your batch file, and some specifics on hardware/versions etc.

Good luck.

Thank you for so much good info.
(In the meantime my rig is down to 8 GPUs, sold one together with the old MB)
I tried working on the dcri value, hash got a little bit better, but I am stuck at the following values:

ETH: GPU0 29.938 Mh/s, GPU1 30.101 Mh/s, GPU2 30.273 Mh/s, GPU3 30.097 Mh/s, GPU4 30.433 Mh/s, GPU5 28.517 Mh/s, GPU6 28.524 Mh/s, GPU7 28.521 Mh/s

The last three GPUs reached 30 without too much overclocking on the old rig. I push the last 3 GPUs until instability (as you can see in my batfile), but it doesn't get any higher than 28.5

This is my current batfile:
EthDcrMiner64.exe -tt 69 -fanmin 55 -y 1 -cclock 1130,1130,1130,1130,1130,1030,1030,1030 -mclock 2065,2035,2045,2035,2050,2100,2100,2100 -cvddc 886,890,889,890,885,888,888,888 -mvddc 885,890,889,890,885,888,888,888 -epool stratum+ssl://eu1.ethermine.org:5555 -ewal WALLET -epsw x -estale 0
pause

GPU0,1,2,5,6,7 are MSI Radeon RX580 Armor OC 8GB

GPU0,1,2,3 are on circuit A of the MB - PSU Corsair HX1000)
GPU4,5,6,7 are on circuit B (tried C as well) - PSU LC-Power Platinum 1000W. Tried them first with the same BeQuiet 1000W PSU I used on my previous rig, where they reached 30Mh/s but even with this same PSU it was 28.5 on the new rig/MB.
Bios of all cards flashed with their separate one-click-patch Polarisbios

Motherboard Asus B250 ME - Bios 1010 (29-3-2018)

Windows 10 Pro - 1709 build 16299.431

Any more tips?
Thanks

[TerranGas]

Hello guys!

Thanks a lot to the whole community! I appreciate any question and especially answer.

I have 2 workers, rx 570/580 ,

first worker 6 cards,  second worker 4 cards.

Recently, came back to august blockchain drivers. As usually, difficulties arise after random windows 10 updates...

1st problem. For 1st worker, hashrates goes down... recently my cards gave 29 stable, now it's more like 26-27... - any advises?
2nd problem. for 2nd worker, I'm not able to use msi afterburner. could someone please assist me in pm or here how I can change (set up) core clock and memory clock manually?

after many attempts, i fear to do something wrong.

I'd appreciate any advices. Me myself is a very young noobie with no tech backgrounds. But it's all about learning, right?
Thanks any help in advance. just aim to put maximum from the setup I have, but every time I have around - 5% efficiency and I wish to do something about it.
I tried new drivers (October, november, april) but with them I have 21, 19, or even 16 mh/s while i remember seeing 27 and even 30...

Thank you, kowtow

[hack4love]

what about etc hard fork will 11.7 do the job

[iSuX]

@Claymore

Saw this today in my log file:

08:38:29:239   4304   checked ETH share on CPU, spent 4ms
08:38:48:975   43b8   checked ETH share on CPU, spent 3ms
08:39:09:055   43c0   checked ETH share on CPU, spent 3ms

Don`t think that is normal.

Nothing to worry about, this is totally normal.
Look back through your old logs, (use grep for example), and you'll see it's a regular event in the log.
Mr Claymore would be the only person who can explain why he's programmed this, but no doubt there is a logical reason.

Side note: Generally, (assuming the programmer is not a total moron), log entries will have some prefix, or suffix, "warning", "error", "OK", "good" etc etc, which makes life easier when searching logs for problem events, or notable events you might like to check on.

Conversely, if you don't see such annotations, and the log entry is not self explanatory, you can generally ignore such entries. (as in they are not things you need to worry about).

And No, it's not a virus either.

Thanks for your reply iSuX. I was just wondering why is there CPU share

Thanks iSuX.  I checked old logs and see that this event is in all of them.  I never noticed it before.  I was experiencing system instability yesterday, checked the log, saw this event, assumed it was a virus, ran virus scanner, removed viruses, and system went back to stable.  IDK how I got a virus, but thanks for pointing out that it's not related to the cpu share.

Like Snake, I would appreciate an explanation from Claymore for why the program is checking for eth shares on the CPU.  Maybe it's checking for a virus mining on the cpu?

@androstan1234
Bummer man, what virus was it you had?

It was called coin-bitminer or something like that.  First time this has happened to me in almost 10 months of mining.  IDK how it happened.  Maybe related to windows 1803 update since that's the only thing that's changed.  But I updated both of my rigs, and both use the same router (really a 4G LTE hotspot).  Only one caught the virus.

On the subject of Virus, sigh, if you take 2 milliseconds to think about that, and you can probably assume a virus is unlikely to have your best intentions to heart, ergo, it's going to do something you'd rather not have happen, well, it's hardly likely to have the moronic goal of hacking the claymore binary to make it mine with the CPU or advertise itself, by writing it's own log entries.
Hahahaha.

I mean, people make stupid viruses, and stupid, lazy, and/or inattentive people fall for them.  I figured, maybe someone found a way to force claymore software to mine on cpu and send shares to their wallet, thinking that a tiny amount of mining on a cpu would go unnoticed.  A side effect could be that the claymore software dutifully reports and logs whatever is going on.  If enough rigs get infected, all those tiny amounts could add up to a decent chunk of free money.  

I bet you watch a lot of sci-fi, lol, jk

Joking aside, you make a lot of generalisations here, and while from a frustration pov, you might call a virus "stupid", probably understandably on an emotional level, but what you describe would be a highly sophisticated piece of software, IF it were even possible at all.

In reality, if one had the time, money, resources and skills to pull that off, it would be highly unlikely you'd then advertise what was done in the logs. Hardly very stealthy, and ensuring alarm bells are going off everywhere.
That ability/means would also be an exceptional asset, and one you would not squander on a poor gain, high risk, and advertising the fact.

More or like less robbing every bank in town, and leaving your calling card, name and address at the crime scene, tripping the fire alarm for good measure, now THAT would be stupid.

Equally, somehow decompiling claymore, and adding in code to CPU mine, recompiling, inventing some delivery method, (very challenging, very not-stupid I assure you), for some paltry gain doing CPU mining, something that would be very obvious to the user, when one already has a GPU miner application, and you could simply deploy a local man-in-the-middle method, and siphon off a share here and there, now THAT would give you some gain, could be quite stealthy, has been done already, the code is out there.

Something to realise is, such actions are generally considered crimes, but these programmers are not stupid people, they are usually highly intelligent, and while their actions in use of their programs is probably stupid, that comes later, before then, the programming etc, is usually pretty sophisticated, cleaver, devious, and very well thought through and engineered, (so as to circumvent all the known detection methods).

As time goes on, these programs get out there, get identified and tagged, and added to antivirus databases.

This is also very big business, and is synergistic with malware, perversely a kind of malware in itself, but certainly reliant on malware programmers, feeding off them in fact.

By this I mean, "I don't want antivirus software on my rigs, but I have to have it because of malware, which is just some other software I don't want".

So, it's in their interest to tag as many applications as malware as possible. Why?
Because it creates fear and worry in people, and makes them purchase anti virus software.

Insurance companies have been doing exactly this for decades. Make people worry about something, then offer them "a solution", at a price of course, and one that ensures the insurance company is in healthy profit.

In fact, if one looks specifically at Claymore, and how it's sometimes identified as malware, proves the point I'm making.

He is an analogy.

A kid goes down the street one night, gets into an altercation, and gets stabbed by a screwdriver.
Weapon = screwdriver.
A builder leaves site the same night, walks down the same street carrying his tool bag, are his screwdrivers weapons?

The VAST majority of software tagged as malware, (weapons)  are actually simply tools, what determines the difference is HOW YOU USE THEM.
This is something the antivirus software vendors turn a convenient blind eye to, as they would have rather have you worried by the millions of malware items they have in their databases.

Anyway, aside from all this, if I might offer some advice.
If you ever get a detection, write it down, use a different computer to research it, make sure you know what it is, IF you need to remove it, and especially the method of infection.
Otherwise you'll probably see it again in the future.

While you might be right, there are a lot of stupid people out there, myself included at times, malware infection is designed to trick people. If you keep stepping on to the playing field, no matter how good you are, sooner or later, you'll be beaten.
Does that make you stupid?

[iSuX]

Built a new rig and my hashrate is down...

Old rig:
MB: ASROCK H81 Pro BTC 2.0
CPU: Intel Pentium G3260 (3.3GHz)
RAM: 8GB - 1333MHz
6GPU

New rig:
MB: Asus B250 Mining Expert
CPU: Intel Celeron G3930 (2,9Ghz)
RAM: 8GB - 2400MHz
updated Bios + Chipset to latest version
9GPU

Dual mining ETH+XVG with Claymore 11.7
Both times Radeon drivers 18.3.1, all compute.
4 of my cards that used to mine ETH at 30Mh/s and now do only 28,3 in my new rig... Those cards are on the same PSU I used in the old rig.

OC/UV used to be 1130 / 2035 / 890 / 890
Tried pushing them to 1130 / 2100 / 880 / 880, but I get minimal gain and seem to have touched the ceiling as I start getting invalid shares and have to get back to safer levels.

This might seem silly, but is it possible I have to flash the BIOS of the GPUs again as the configuration is different? Latest Windows10, so problems with ATIFlash to check... :-(

Thanks for any help

Hey there
"Latest version" is not very informative, such things have numbers for good reason.
Now, that said, there isn't enough data here for a differential analysis, nor any explanation as to why you are thinking, OC or BIOS as candidates.

Assuming you didn't change either of those (OC/Bios) when you migrated your GPUs, from old rig to new rig, (did you?, as you mention 6 GPUs in old rig, and 9 in the new rig), so are 6 of those GPUs moved from old to new rig, and now seem to be hashing slower?

What make/model GPU?

Also, what is far more relevant here is, new motherboard, new ram, new cpu, new OS, new install of everything, and assuming you didn't change BIOS or Claymore config, I'd strongly suggest investigating all the former, before turning the spotlight on the latter.

Some things to consider.

What OS version on both rigs?
IME Win10 Home version out performs Pro in almost every respect, gaming or mining. For one, it's loading a LOT less MS-crap that most people don't need. (If you're not joining a domain, you probably don't need Pro). The number of services is nearly double on Pro, and again, probably you don't need any of the pro stuff for mining.
Mining and stability go hand in hand, and keeping the OS as lean as possible, updates disabled, (set all NICs to metered connection), and manually control/manage how/when you plan on updating, (if at all).

FYI, I also have one rig on the B250ME, and have no issues with different hash rates given same GPU/driver/claymore ver. (I also moved GPUs to that rig, and from it, as I was able to consolidate same make/model/ cards on it) (mixed mem type still, and no issues).
This has been so since day 1 with the B250.
Where the B250 did become a pig, was getting it stable with the 12th GPU, and worse still with the 13th.
That said, spot check, clocking through 75 hours, (claymore 11.7, Win10-64Bit-Radeon-Software-Adrenalin-Edition-18.3.4-March23, Win10Pro 10.0.14393) which is not a record, but I had to reboot last Sat), but the B250 is running well these last 4~5 weeks.
(13x RX580) Sapphire, mix of Hynix/Samsung/Micron2, all on custom BIOS, all hashing >32.

But as you asked, I HAVE seen some issues with ATIWinflash.exe, I've certainly taken some shortcuts, and regretted it. If nothing else, shortcuts add an element of doubt when analysing issues later on, and in some situations, you're unable to quantify those, (doubt remains).

When working with networked systems, by "networked" I mean, multiple computers, (gpus), in a single entity, it's paramount to be systematic, anal always helps :-)

Some tips.
Note the serial numbers of your GPUs, backup the BIOS before you do anything, (use the serial number in the bios file names).
Start off with stock BIOS, (for some days), so you establish a reasonable baseline of data.
GATHER data, write it down. What is "normal" for each etc
Make sure you know which GPU number (in Claymore, in GPU-z, in Radeon-settings), is which, and that way, you know what you are changing, (and can revert), and most important of all, DIFFERENTIATE when you see issues.

I've seen stock BIOS on RX580s, as low as 18MH/s and typically no higher than 29MH/s.

If you mod the BIOS, work on only ONE GPU at a time, version your BIOS edits, (CardMakeModel_SerialNumber_Ver) or something to that affect.
Key point is, make SURE it's clearly identifiable.

Get yourself a METHOD, you are going to end up managing and maintaining a complex system, there are a LOT of variables, so with a standard method, you can at least hope to rule out all the dumb human elements.

Easier said than done, and one should consider "method" a work in progress, refine that as you go along, and maintaining rigs DOES get easier with experience, and systematic analysis.

One thing about fine tuning BIOs: Initially I was struggling to break 30MH/s and made some mistakes,  identified dead ends, had some cards that were real pigs, but actually turned out far better than I expected, even on more than one occasion considered returning.

Try to use all the same make/model/mem-type of card if you plan on a small operation, (<10 GPUs).
I don't say this to cherry pick, or exclude any vendor, but simply because with a small number of cards, it's very hard to know what ""normal" is for them. If you have only 1x Asus RX580, how do you know if it's good/bad/ugly? If you have 2 or more, you can at least hope to make some comparisons.

Also, don't believe everything you read online, (and feel free to ignore me :-) but MAN I read a lot of utter RUBBISH online. In fact, finding the accurate data is the toughest challenge.

One example, that still puzzles me, (note: puzzles me, not saying it's rubbish), is how many people rave about Samsung memory. In my experience, Samsung has been the best out-of-the-box GDDR5, but also the toughest to fine tune. In fact, I'd suggest it's not even worth trying memory strap edits with it.
Drop the power consumption & core clock, up the memory to 2250, and you should be seeing 32.5, and stable. I wasted a lot of time trying to better that, only because I didn't see a big jump, and due to hype, assumed Samsung was the fastest.
By the time I got my hands on my 2 and only Samsung GPUs, I had Micron running super stable at 32.6, up from 29~30 stock, and (mistakenly) figured I could see similar gains with Samsung.

My present conclusion is, Samsung mem is already pretty tightly dialled in, so as an out of the box card, it's certainly the best I have seen, but it certainly is not the top performer in my rigs.

Some notes on BIOS editing.
Make sure you have a versioned stock bios file saved.
Use THAT file for editing. (Do not use BIOS from the net).
Depending on the card and editor, it's highly likely there are other bios elements that are not displayed or editable in the bios editor. Who knows what you change if you flash some random BIOS from the net.
Make sure you have only a single card connected when you flash.
(For SURE, I have done a enmasse deploy to 3 GPUs on multiple occasions, and in recent weeks identified that as a 100% confirmed issue). 2 different rigs, 1~2 cards started to show got incorrect share, after some hours.
What was weird was, those were all cards that were mass-flashed.
What solved that?

Several things.

Shut down rig, bleed down power, remove all but 1 GPU (usb cable), boot up, flash that one card, (I used the same BIOS ver for that same card as last flash), do NOT click ok to the "you must reboot message", but actually shut down, and bleed down the power.
I have a suspicion the dual BIOs cards are capable of holding the BIOS in DRAM and not actually booting to the newly flashed BIOS.
Sure, that will depend on the architecture of the card, but BIOS is typically EERAM, or some similar flash ram type chip.
The card is NOT going to use this (new program), unless several things happen.
A flag/trip is set, (by the flash app), to reload BIOS, (this seems to fail sometimes with Winflash), but for sure, what will force the card to load the new BIOS on next boot, is removal of power, (bleed-down), as this clears the DRAM, and leave the card no choice but to load from EERAM.

Did you notice how slow it is to program BIOS? Those are usually 256 or 512 KB chips. That is KB, KB, nothing these days, yet flashing takes nearly 1 minute for 512 chips. Sure the write speed is slower, but even the verify is slow, and this is because the eeram is not intended to be fast, or used much, (written to), but is depended on to safely store data, without any powered backup.
What typically happens is, as soon as power comes up, the dram content is crc checked with eeram, if ok, card boots, if not, it loads from eeram. As this happens at power on, before os init, that causes no delay in booting. What the winflash does is cause change in crc, and that SHOULD trigger the card to load the bios from eeram on init, but this has certainly failed for me.

I saw no change in card performance after flashing. Stopped claymore, opened winflash, saved BIOS, and sure enough it WAS new, so flash was ok. I shut down, bled-down power, rebooted, and THEN I saw the improvement I was expecting.

My point is, that winflash is only able to read the bios from the eeram, NOT from dram.

Basically you can think of it much like your computer, eeram=hdd and dram=system memory.
This architecture is not so by accident.

The purest will also say you should not use winflash, but rather boot to a very light os, (Dos), and flash from there. This is actually very good advice, but I decided I'd use that as the fall back, and at least start out with WinFlash, as it IS vendor provided after all.


But for sure, it has it's use case, and multiple flashing is a time-saver I've decided is not worth the gain.

But at the same time, I've yet to see those issues insurmountable.

OK, last work on OC.
OC is pushing your luck, if you see issues, remember, you are pushing your luck.
As for the silicone lottery, at least with Sapphire cards, having built rigs for a few people now, I've only had 1 card out of 30 something, that was clearly a dud.
BUT the only way I can say that with certainly is because I documented all the 30+ other cards, (same make/model/memory), and no matter what I did to that one card, it was not stable with any oc at all.
Is that the silicone lottery? I don't think so, I think it was simply a QC issue.
I could be wrong, maybe someone with 100+ cards, data, and experience can chime in here.



OK< last thing.

Did you try setting the dcri?

New rig has 9 GPUs, cmiiw.

DCRI will be different for sure.
Disable dual mining for a start, (pointless, no profit unless you have free power, and even then dubious imho).
Try the "z" key during solo mining, and let claymore find the optimum.
If those numbers are very different from your dcri value, (>2) then I'd suggest at least picking the mean for your config file.

What happened to your hash rate after "z"?

Side note, and no disrespect to Mr Claymore, but usually I find a better dcri value, by using the -+ keys, and set same for all gpu.
But for sure, the z key is a nice feature and great tool to get you 95% optimised and quickly.

Also, set -y 1 check your console during init and make sure you see both lines below.
 
All AMD cards use Compute Mode already
CrossFire is disabled already

 
Otherwise, open admin console, start your batch file as usual, wait for the "all cards now use computer, please reboot"
Reboot, and run claymore as normal, (no need for admin).

THIS IS THE BEST FEATURE from Claymore of late, if you have more than 5GPU, otherwise it's hours of lame AMD-settings, and reboots, to configure each GPU.

Finally, if still no luck, post your batch file, and some specifics on hardware/versions etc.

Good luck.

Thank you for so much good info.
(In the meantime my rig is down to 8 GPUs, sold one together with the old MB)
I tried working on the dcri value, hash got a little bit better, but I am stuck at the following values:

ETH: GPU0 29.938 Mh/s, GPU1 30.101 Mh/s, GPU2 30.273 Mh/s, GPU3 30.097 Mh/s, GPU4 30.433 Mh/s, GPU5 28.517 Mh/s, GPU6 28.524 Mh/s, GPU7 28.521 Mh/s

The last three GPUs reached 30 without too much overclocking on the old rig. I push the last 3 GPUs until instability (as you can see in my batfile), but it doesn't get any higher than 28.5

This is my current batfile:
EthDcrMiner64.exe -tt 69 -fanmin 55 -y 1 -cclock 1130,1130,1130,1130,1130,1030,1030,1030 -mclock 2065,2035,2045,2035,2050,2100,2100,2100 -cvddc 886,890,889,890,885,888,888,888 -mvddc 885,890,889,890,885,888,888,888 -epool stratum+ssl://eu1.ethermine.org:5555 -ewal WALLET -epsw x -estale 0
pause

GPU0,1,2,5,6,7 are MSI Radeon RX580 Armor OC 8GB

GPU0,1,2,3 are on circuit A of the MB - PSU Corsair HX1000)
GPU4,5,6,7 are on circuit B (tried C as well) - PSU LC-Power Platinum 1000W. Tried them first with the same BeQuiet 1000W PSU I used on my previous rig, where they reached 30Mh/s but even with this same PSU it was 28.5 on the new rig/MB.
Bios of all cards flashed with their separate one-click-patch Polarisbios

Motherboard Asus B250 ME - Bios 1010 (29-3-2018)

Windows 10 Pro - 1709 build 16299.431

Any more tips?
Thanks

No worries.
OK, what was immediately jumping out at me here, is how highly tuned your config file is.
In comparison, I run all my rigs with identical settings for all GPUs, no card specific clock, voltage settings, (except 1 single card, an ASUS Dual, (a BAD choice I have come to realise, really REALLY shitty fans, 1 failed after 2 weeks, the replacement card failed 2 days after amazon 30day returns, anyway, I won't bore you with that story, but I down clocked it to keep it cooler).

What I wonder here is why, with 6 identical GPU, do you have them dialled in so tightly?
For sure that is accounting for the differences you see between those 6, do they have different memory?

FYI, I've found Micron to be the best, (MT51J256M3 (MICRON)) also the one you'll probably read a lot of people moaning about too, and I confess, WAS a bit of a challenge, but also a learning curve for me.
Samsung is very good, imho the best I've seen, out-of-the-box for mining,.
Hynix and Hynix2, seem to be a bit petulant, and I probably need to do more work on refining those, but
My point is, regardless of memory, I have no RX580 8GB cards running below 32MH/s, all have identical clocks and voltages, regardless of vendor.

What I would say is, with your current config file, it's impossible to make any comparisons, and therefore any differential analysis is pretty pointless as it is.


Also, your batch file is kind of a shambles :-) I don't say this as a criticism, but it makes it easy to make mistakes or miss seeing them, and I'd suggest you reorder that file, as per claymore examples.

Also, I see some odd choices in there, why are you stratum mining SSL at Ethermine?

Try this config, assumes you have populated your epools.txt file, you SHOULD get min speed 256, but I set this to 200 for now, otherwise you will get 5 min restarts below that level etc

Make sure you have virtual memory to 48000, (should be enough, I have that on a 13GPU rig, with 16GB ram, no issues)


setx GPU_FORCE_64BIT_PTR 1
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
EthDcrMiner64.exe -epool ssl://eu1.ethermine.org:5555 -ewal WALLET.RIG -epsw x -checkcert 1 -epoolsfile epools.txt -minspeed 200 -gser 1 -esm 0 -etha 0 -ethi 16 -eres 2 -erate 1 -estale 1 -asm 1 -platform 1 -y 1 -dcri 9 -wd 1 -ftime 5 -r 14400 -cclock 1200 -cvddc 900 -mclock 2250 -mvddc 850 -tstop 83 -tstart 50 -tt 69 -fanmin 55 -fanmax 100 -ttdcr 80 -ttli 80 -mode 1 -dbg 0 -altnum 3 -mport -3333 -mpsw whatever -logfile logs\

Now, with your cards, claymore might not init with -mclock 2250, so if that happens, change that to 2100, (stock for RX580), and see what happens.

If you need more help, please list each GPU number, make model, memory, and some logfile showing hash rate, it might be possible to spot something when every card is running the same settings, (or even stock settings for all is a good idea in this situation, as the data should be solid for analysis)

Also, you could try running with the -di 0 parameter, (GPU0 only), and tuning that up, (probably dcri 4~6 will give better rates with a single GPU, but you will have to experiment on your own rig).

To be clear, if I were approaching this situation, my working logic would be to break this down, it has 8 GPU, pick the worst performer, remove the others, and get that one GPU to 32MH/s something, by the time you get there, you should have the experience/know-how to apply to the others.
If you have only a single rig, you can also run another instance of claymore with the parameter, -di 1234567 which will allow you to at least mine with the other cards while you focus on pumping up GPU0 to 32MH/s

I'd also be interested to see a screen shot of gpu-z and polarisBios editor for GPU0, or GPU7.

But for sure, something is very wrong there, (or those MSI cards are rubbish, (and I don't think I recall hearing they are, in fact a lot of miners use them, but I have none myself), but what I can say is, while I tried to stick with Sapphire, during late 2017 and Q1 2018, with shortages as they were, I ended up with some ASUS DUAL, (bad choice), Gigabyte Gaming, Aurous, (a bit tricky to bios edit initially), but regardless all are stable at 32MH/s, so your 28s look really painful man.

Still, on the plus side , you have a nice gain of 28MH/s to aim for right now, and assuming those MSI cards are up for it, that should be achievable.
Good luck man.

Foot note: Thinking a bit more here, I wonder if there is a correlation with 28.5-ish rates and BIOS. There might be no connection of course, but it's interesting that 28-ish is usually what I see with out of the box BIOS. Then again, your clocks are all over the place, so hard to know. Worth following up on, if only to be discounted.

[powvex]

2 Big problem I have and I'm sure its happened to many others:

1- Claymore dont recognize gpu temp and fan speed but GPU0 if you connect with RDP and run claymore there.
2- Windows update 1803 ruined everything, and no more claymore running or ATIFlash after updating to 1803. Damn microsoft for that.

[iSuX]

OVERLOAD!

Background:
In the early days of my mining project, I had managed to get 2 rigs stable.
They were built in succession, so the RIG1 had been running non-stop for some 7~8 weeks, ahead of RIG2.

These rigs used a few different PSUs, all Corsair 1000W, RM1000x, HX1000, HX1000i.

At about the 3 month point, RIG1, hit a bump, "random" reboot, (it's was running a USB watchdog, so I was unsure if this was the trigger, and disabled it for testing purposes), equally, event logs only mentioned kernel power, which is pretty vague.
Fortunately, things went downhill fast, and I stripped the rig down for inspection.

Cutting to the chase here, the problem was traced to the SATA/Peripheral 6pin plug on the PSU itself.
In this case, the connector was melted on the 12V pin, the pin welded into the cables socket, and all the insulation crumbled on the plug/socket, and melted some 2cm up the wire itself.

Now, I had failed to appreciate a number of things, and these are worth sharing.
The plugs are rated 10A, but in reality, one should not assume to work anywhere close to that "limit" for 24/7 operation.
Usually about half that is a safe maximum.

Why I didn't pay attention to a glaringly obvious stupidity on the part of Corsair is my own fault.

The Corsair, (and cables of all the PSU vendors for that matter), all have 4 Molex connectors in parallel. Now each Molex is rated to 10A, so how can one expect to pull half that, x4, (20A) through a single 10A plug/socket on the PSU?
Or if you want kindergarten logic, pull 4x 10A (molex) (40A) through a single 10A outlet?

I had stupidly assumed the PCIe risers were mostly inert, as power would in the whole come direct to the GPU.
WRONG!

In all cases I had used all 4 of those cable headers, whether those be molex or SATA power, and in all cases there were clear signs or damage after 3 months. (<2 months on rig2!)

I've rewired all my rigs, maximum 2 devices (PCIe risers, SSD, relay, fan-banks) per cable.

The Corsair PSU in all cases failed to trip safety cutouts, at least the HX1000i didn't log that it had, the RM1000x and HX1000, have no datalink so maybe they did, I have no way to tell.
But equally, this kind of failure is unlikely to cause a trip out, because the PSU is actually delivering LESS power, as current flow is inhibited by the degrading plug/socket!

I shipped 3 PSU back to Corsair.

Signs to look for.
Has a previously stable rig, become unstable, and you didn't change anything, drivers, hardware, etc?
Do you have more than 2 devices on a single power cable?

Checks/Inspections
Power off all PSUs, remove AC plugs, then remove the cable-sockets from the PSU outlet plugs.
Inspect the pins in the PSU outlet plugs.

Warning signs include: Pins no longer shiny/silver/gold, but dull, oxidised, black or burned.
Gently flex the cable near the FAR end of the cable, (farthest from the PSU), this should give you a feel for GOOD cable flex, (normal for THAT cable). Now repeat that flex-test at the other end of the cable, (right where it comes out of the PSU plug).
If you feel less flex, or it could be like a solid rod, no flex, that is a clear sign of overload.

This is a vicious cycle, as you overload, the wires heat up, they expand and abraid on each other, and oxidise. They do this more, right next to any connection, because there is a break in the insulation, allowing the ingress of air, and the oxygen component accelerates the oxidisation. The cables loose flexibility because of this, and also heat up more, accelerating their demise, in extreme cases this will melt away the wire insulation, and even the plug/socket.
If there was ANY human element during manufacture, (skin oils on the wires during handling, crimping, poor stripping, stand damage, poor crimping, bruising), these will drastically increase the likelihood of failure, especially if you pull more current through them.

ALL these signs were present on all my RIGs!!!

All have been rewired 2 PCIe risers per power cable, and 6 weeks on, all reinspected and there were no signs of degradation. A further inspection was done 2 months later, and again there were no signs of overload.

I have a feeling there will be MANY miners out there, who didn't give much thought to plug/socket ratings, and trusted the vendors would be using safe practice, WRONG!

Think: National Lampoons Christmas Vacation, (the Christmas lights scenes), because Evga, Corsair, and all the other vendors are shipping time bomb cables, and NO WARNINGS on them, or the PSU manuals.

Using 3 of the 4 headers might be ok, I opted for maximum of 2, because this is standard/safe practise in situations like this.


REPEAT:
Signs to look for.
Has a previously stable rig, become unstable, and you didn't change anything, drivers, hardware, etc?
Do you have more than 2 devices on a single power cable?

Finally: Don't jump to conclusions about Claymore or OS, or drivers, until you're satisfied the hardware is OK!


Good luck everyone.

Sorry to rehash the whole post, but damn I wish you had posted this two months ago - i spent weeks and plenty cash changing so many components only to find them burnt on the SATA connections on the psu port. We always look at risers etc but the real cost here is psu as they cost the same as a gpu and it isn’t safe based on this principle on a 6 card rig anymore. Cheers iSux- thanks for sharing

Ahhh, man, I'm sorry, you are right, I should have got around to posting this earlier.
ACTUALLY, in my defence, I DID write this up back in March, had most of it down, and palmed some key combination, (bottom left of keyboard), and the bitcointalk page refreshed and I lost the lot, I walked away in frustration, and an hour something lost.
Actually that has happened a few times before, since, and even this morning, I have tried to work out what the hell does that, but it's bloody annoying.
For bigger replies I use notepad now and paste in here.

Anyway, I feel your pain man.

BTW: It should be obvious, but I'll point this out now, as it missed this draft, FIRE FIRE FIRE!

Running rigs, (a lot of fans), these actually do a fine job, pardon the pun, of chopping up airborne dust, in fact, the added airflow scavenges dust, with added convection, a fine coating of dust will accumulate over time.

If you're not already considering it, I'd suggest scheduling a regular maintenance window of down time, to clean and vacuum away as much as practically possible, (heat sinks, fan blades,  any area with a heat source).

In reality those heat sources (e.g. chips) will not be enough to ignite a fire, but they will hold an accumulation of flammable dust at a nice starting level, ripe for a spark from a melted PSU cable for example.

No need to overreact here, but if you're not thinking about this angle, you''d do well to consider it imho.
Safety First!

[iSuX]

2 Big problem I have and I'm sure its happened to many others:

1- Claymore dont recognize gpu temp and fan speed but GPU0 if you connect with RDP and run claymore there.
2- Windows update 1803 ruined everything, and no more claymore running or ATIFlash after updating to 1803. Damn microsoft for that.

Did you look at the

Readme!!!.txt

Funny Claymore as added more !!! to that file name, but with posts like this, it's no surprise.
I wonder if Readme!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.txt would help ;-)

Why did you update the OS?
What problems did that solve for you?

[iSuX]

Hello guys!

Thanks a lot to the whole community! I appreciate any question and especially answer.

I have 2 workers, rx 570/580 ,

first worker 6 cards,  second worker 4 cards.

Recently, came back to august blockchain drivers. As usually, difficulties arise after random windows 10 updates...

1st problem. For 1st worker, hashrates goes down... recently my cards gave 29 stable, now it's more like 26-27... - any advises?
2nd problem. for 2nd worker, I'm not able to use msi afterburner. could someone please assist me in pm or here how I can change (set up) core clock and memory clock manually?

after many attempts, i fear to do something wrong.

I'd appreciate any advices. Me myself is a very young noobie with no tech backgrounds. But it's all about learning, right?
Thanks any help in advance. just aim to put maximum from the setup I have, but every time I have around - 5% efficiency and I wish to do something about it.
I tried new drivers (October, november, april) but with them I have 21, 19, or even 16 mh/s while i remember seeing 27 and even 30...

Thank you, kowtow

Hey there, it's not really possible to give you any specific advice, as there is no detail about your rigs, hardware, os version etc.

But what stands out are a number of  common follies with prepping an mining environment.

Most of the suggestions I could offer I've already posted, so suggest you take a look at those posts, last 2 weeks etc, and find the best best-practice methods that work for you and your rigs.

A key point copied here below, (updates) but make sure there is a specific gain FOR YOU, (a problem YOU have, that is documented solved in the update), otherwise you probably don't need it or the hassle.
Dedicate your rig for mining, no wallets, no web browsing, no exceptions, keep defender (or whatever) ON, and set exclusions only if need be.

Mining and stability go hand in hand, and keeping the OS as lean as possible, OS updates disabled, (set all NICs to metered connection), and manually control/manage how/when you plan on updating, (if at all).

Side note: Why did you go back to the blockchain drivers?
Those were and are Beta, they are also very old now, the releases since, have rolled up those refinements, and so choosing an old beta version needs some explanation.

(Don't forget to use the -y 1 parameter, or lame AMD setting to set all cards to compute)

Side note: I never allow ANY windows updates on my rigs, all have stock OS deploy, and all update services removed or disabled. I consider the OS a throw-away item, if it gets trashed, I redeploy the stock image, and so far, have never needed to do that.
Use CCleaner to remove all the MS garbage, all the tiles and crapps, all the xbox rubbish, EVERYTHING you can remove, remove it.
Keep your os firewall on, make sure you know how to use it, and what exceptions and rules are in place, stay behind a hardware firewall, dedicate the rig for mining, no email apps, no browsing as I said, don't install anything else, keep defender up to date, and scanning and secure the hardware, and you're pretty much safe for the most part.

Remember, most security breaches these days are by tricking you to do, (install) something you don't want, or expect to do what it advertises to do.
Ergo, YOU are the biggest risk, not Microsoft, or whatever vendor.

If you need any convincing of the unsuitability of changing the OS with constant updates, look no further than this very page in this forum. Or almost any page for that matter.

Bottom line is, we all want our rigs to RUN 24/7 and stable, so why people see the need to destabilise them with updates is a question worth asking.

Stability = unchanging!

End of debate on that subject if you please.

Finally, if none of this helps, summarise (itemise) your hardware, versions, expectations, batchfile, and results.
Essentially, be specific and detailed, otherwise advice will be best guess, and probably well off the mark.
Good luck.

[powvex]

A noob question;
Is memory overclocking work with RX560? mine will not change by -mclock 2000 and got stuck on bios.

[iSuX]

A noob question;
Is memory overclocking work with RX560? mine will not change by -mclock 2000 and got stuck on bios.

Hey there
I'm sure what you mean by "stuck on bios" though??
(FYI, this statement actually makes no sense at all probably, because if the BIOS failed to init, (actually the VERY first thing when you power on a PC, before the CPU, or motherboard), then you would not even know that RX560 existed in your rig.

FYI, the reason the very first thing in a PC that completes init is the GPU, is so the monitor is able to show the user what happens next, (the mb init and boot up etc).
This is of course not always entirely true, if you have multiple GPUs for example, because the BIOS on the motherboard only waits for the first GPU to complete init, then it un-pauses and runs it's own init sequence.

But when you say "overclock", that implies you know what the default clock is to start with, and equally the limits etc.


One way to find that out would be to use GPU-z, which will display the defaults, and the current values.

Like anything, there are limits, those can vary by vendor, model, etc, so one way you could find out about your card, (for sure, rather than believe what people might tell you), is to use ATIWinFlash to save your factory BIOS, then open it in PolarisBiosEditor.
Left pane, second box down, "PowerPlay" there will be a value for "Max Memory Freq. (MHz)" and whatever value you have in there is the absolute maximum the card will accept.

I could be wrong, but the RX560 is not such a common card in mining rigs, and I mention this because all the example batchfiles you see posted, are actually specific settings for specific cards, so don't assume you can use for example, RX580 clock limits (2250) on the RX560.

Maybe you can, maybe you can't, check for yourself on your cards, as above, then you know for sure.

Just out of interest, what hash rates are you seeing on the RX560, with what settings, (post your batchfile).


Post a bit more detail, if you need help, problems you're seeing, expectation not being met, detailed info on hardware, enviro,  drivers.

Good luck.

[powvex]

A noob question;
Is memory overclocking work with RX560? mine will not change by -mclock 2000 and got stuck on bios.

Hey there
I'm sure what you mean by "stuck on bios" though??
(FYI, this statement actually makes no sense at all probably, because if the BIOS failed to init, (actually the VERY first thing when you power on a PC, before the CPU, or motherboard), then you would not even know that RX560 existed in your rig.

FYI, the reason the very first thing in a PC that completes init is the GPU, is so the monitor is able to show the user what happens next, (the mb init and boot up etc).
This is of course not always entirely true, if you have multiple GPUs for example, because the BIOS on the motherboard only waits for the first GPU to complete init, then it un-pauses and runs it's own init sequence.

But when you say "overclock", that implies you know what the default clock is to start with, and equally the limits etc.


One way to find that out would be to use GPU-z, which will display the defaults, and the current values.

Like anything, there are limits, those can vary by vendor, model, etc, so one way you could find out about your card, (for sure, rather than believe what people might tell you), is to use ATIWinFlash to save your factory BIOS, then open it in PolarisBiosEditor.
Left pane, second box down, "PowerPlay" there will be a value for "Max Memory Freq. (MHz)" and whatever value you have in there is the absolute maximum the card will accept.

I could be wrong, but the RX560 is not such a common card in mining rigs, and I mention this because all the example batchfiles you see posted, are actually specific settings for specific cards, so don't assume you can use for example, RX580 clock limits (2250) on the RX560.

Maybe you can, maybe you can't, check for yourself on your cards, as above, then you know for sure.

Just out of interest, what hash rates are you seeing on the RX560, with what settings, (post your batchfile).


Post a bit more detail, if you need help, problems you're seeing, expectation not being met, detailed info on hardware, enviro,  drivers.

Good luck.

Thanks for the answer.

Bios memory clock is set to 1750, and the memory is Hynix. My problem is; I cant use -mclock 2000 to set the memory clock by claymore, but I can set it with Overdriventool and wattman to 2000MHZ with no problem.
Also I've tested and I can set it a bit more further to 2100MHZ with those programs without any problem, and its still solid rock stable. But again, I cant change it with claymore.

I'm measuring all sensors and clocks with GPUZ, And for sure, with hashrate too.

I've reached 15.758 MH with overclocking and undervolting with ease and no problem.

For the info, This rig is my side rig, and I've set all others with RX580, not rx560. But as they're exist in my inventory, I should use them too.

[robminer80]

I've reached 15.758 MH with overclocking and undervolting with ease and no problem.

I've a rx560 Hynix too, which timingstraps/clocks do you use to get 15.8MH? I can't reach 15

[phoxpup]

I want to report maybe a bug , Using 11.7:
When I try to start Claymore:
miner@newrig_rx:~$ ./clay/start.sh
/home/miner/clay/ethdcrminer64: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3' not found (required by /home/miner/clay/ethdcrminer64)
^C
miner@newrig_rx:~$ lsb_release -a
No LSB modules are available.
Distributor ID:   Ubuntu
Description:   Ubuntu 18.04 LTS
Release:   18.04
Codename:   bionic
Probably, I think there is bug with Claymore - looks for CURL_OPENSSL_3 and not newer versions, because with libcurl3 installed - it works fine, but it doesn't work with libcurl4 (default lib).
Read for some fixes for ArchLinux (They didn't work to me on Ubuntu), but I think that with using Ubuntu 18.04 more and more people will see this error.
Thank you in advance.

Ok I'll check it.

Yes, I upgraded my ubuntu 16.04 system to 18.04 and it broke Claymore's Dual Miner.  Running even the latest V11.5, it was broken.  One "sudo apt remove libcurl4 & sudo apt install libcurl3" and I was rolling.  And before anyone goes and tells me this is a bad idea, I  know it already and thank-you in advance. :-) 🦊  I'm looking forward to seeing a Claymore Dual Miner that works with libcurl4 so I can move everything on to 18.04. :-) 🦊