Hahahaha, Oh man, I feel your pain.
Oh, one last thing, the PCIe slots on the asrock h110 pro btc are REALLY close together.

One of the problems I observed was how easy it was to introduce instability by dislodging the PCIe cards in the slots.
I'd start out with one problem, and introduce another because the USB3 cables can easily unseat, or rotate the PCIe cards in the slots.

I decided to string them all together, as they have 1 hole in the over-hang, and I used nylon standoffs, to "bolt" all the PCIe cards into a single bank.

I used these

https://www.amazon.co.uk/260pcs-Black-Spacers-Stand-off-Assortment/dp/B01GVD146I/ref=sr_1_1?ie=UTF8&qid=1526890885&sr=8-1&keywords=nylon+standoffs

Of course it's not quite so easy to change a failed PCIe, as you have to remove the whole bank as one, but it only adds a minute or two, and the added stability, (and chance to rule out that failure variable) is well worth it.

I wonder, with the asrock h110 pro btc, the slots are SO close to each other, if it's possible for the USB socket on one PCIe card, to tip/tilt over, and short on the back of the adjacent card?

Anyway, something to check, think about.

Good luck.


 

That looks painful. Without knowing anything about your rig, hardware, os etc.
Two things come to mind.

1: Set log to debug mode "-dbg 1" see if you get more clues.
2: Check your hardware. Power down, bleed down), (search for my previous post, "bleed" for explanation on that topic).
Hardware Checks: Remove all GPUs except 1, see if Claymore gets further through the init.

(You should be seeing it initialise OpenCL or Cuda at that point).
If it were a driver issue, you'd see that "missing" and you don't, so I'm thinking your issue is more likely hardware than OS/driver, and it's not Claymore for sure.

I don't know what debug will print out in this situation as I have never encountered it, but debug is certainly the very first thing you should try, because if you have a permanent fault condition, you want to gather as much data as you can, while the fault is present, BEFORE you start to change anything, or reboot etc.

In terms of fault finding, permanent fault conditions are easy to track down compared to seemingly random, intermittent type issues.

If you don't get any further, post a summary of your RIG spec, (look at the post from iRrromka, because his post is how you do that correctly).

Good luck

Your RIG and component selection/quantity is very similar to one of my RIGs.
Actually, I have scaled back from 13GPU, max 4x RX580 per 1000W Corsair, (assuming 1 PSU is also powering MB).
I did build a 13GPU rig for someone, and it IS super stable, but it was a long fight to get there, and I'd estimate it cost at least 1 month of downtime before I felt that is really stable.
That is 1 month of lost mining time, and a LOT of my time, Given it was super stable at 10GPU, loosing so much time for the 11th, 12, and mostly 13th GPU makes me consider if that was worth it.

Of course, given payback time mining, it WAS worth it, but one can only say that with hindsight, and I've actually settled on 8GPU as a max per rig, (with 1000W PSUs), simply because I can build that up to super stable in half a day, and have a pretty high certainty it will be mining after 5 hours, and at what hash rate.

The problem is, with more and more GPU per rig, down time REALLY starts to hurt more and more.
Even rebooting a 13GPU rig, that is 13 GPU doing nothing.

Don't get me wrong, I learned a lot from that 13GPU project, it's actually a Asus B250, so has another 6 slots free, but adding in Nvidia at this stage, means shutting it down, 13x GPU doing nothing.
Now, if it was unstable right now, that might be different, but it's super stable, I don't even reboot it, I was hoping for a new run-time record on it actually, but had a damn power cut last week, but it still holds the record in all my rigs, (170 hours) nonstop (until the power cut), and that is Claymore too of course, no restarts even.

Anyway, good luck, and kudos on the 13GPU rig man :-)

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.

Hey, was this rig ever stable?
To put it another way, is this a new issue, and previously this rig was stable?

One thing I wanted to post on, PSUs, deserves it's own post, so check back in 30 min, I'll write it up now.
Good luck btw.

Log File?

This is a weird request, did you actually look at the timestamp in the claymore log?
Or even look at the log?
Here is an example.

11:09:18:605   218c   
11:09:18:605   218c   ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
11:09:18:605   218c   º                Claymore's Dual GPU Miner - v11.7               º
11:09:18:620   218c   º              ETH + DCR/SIA/LBC/PASC/BLAKE2S/KECCAK             º
11:09:18:620   218c   ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
11:09:18:620   218c   
11:09:18:620   218c   b581
11:09:18:839   218c   ETH: 10 pools are specified
11:09:18:839   218c   Main Ethereum pool is eth-eu.maxhash.org:11011
11:09:20:668   218c   OpenCL platform: AMD Accelerated Parallel Processing
11:09:20:683   218c   OpenCL initializing...

11:09:20:683   218c   AMD Cards available: 8

As you see, Claymore took an ENTIRE TWO SECONDS to tell me how many GPU are present.
I defy you to better that by running some pointless info-only batchfile, read the output, e.g. all gpu present and accounted for, then run the actual start batch file. (in under 2 seconds).

Why don't you investigate why your rig is so unstable, that it needs stop, start, fail, reboot, before mining, THAT is indeed wasted time, it also indicates far more serious underlying issues with your rig, issues likely to cause stoppages, crashes, and forcing you to reboot, THAT is time worth saving, but is not solved, assisted or aided by this request imho.

Send some info on your rig, os, versions, hardware, check your system event logs, follow best practise guidelines, (no updates unless there is specific mention of a "something" you need, a problem YOU HAVE, that is specified solved etc), disable all services not relevant to mining, remove all scheduled tasks, lean-rig philosophy etc.

Ignore everyone who gives advice such as "update your driver" without actually specifying WHAT version they mean you to use, (moronic in the extreme!)

Read the claymore readme, especially the last sections.

If all else fails, divide and conquer, (remove half your GPUs/risers,cables, power cables, headers, and run the rig, if it exhibits the same issues of instability, remove that half of the hardware, and add back the other half. If that is stable, you can narrow down by adding back, half the other half removed hardware, (1/4 etc), keep dividing order/half, and eventually you will find the cause. Systematic, quantifiable testing and analysis.
Working by halves exponentially increases the odds you'll find the cause, (faster than one by one etc), and it also covers situations like too much load on psu for example.

Work with all clocks and powers at the factory settings, until you're confident it's stable.
THEN start the OC, and hard-core stuff.

Remember, if you're overclocking, you're pushing it. Some hardware is more tolerant than others, equally, you're possibly shortening the MTBF, so don't assume stability is a permanent situation, given time, there will be degradation, THAT is an absolute certainty.  

Good luck.

Interesting question, why would you want to do that?
Pools relates to, (references), the pool and fallback pools you're mining with.

dcri relates to the hardware, tuning etc, (no relation to pool, at least not that I can see).

What situation are you trying to solve here?

Note: You can very easily have multiple batch files, containing a full config set, or use the config.txt for hardware setup, (dcri etc), and use a simplified batchfile to start, (referencing config.txt and pool.txt files).

Claymore is pretty nicely architectured in that sense, multiple configuration methods, depending on your use case or preference.

Also, a note on "moving", changing architecture in such a drastic way, is generally a very bad idea, unless there is a specific showstopper bug, (not likely in a more mature package). But essentially if you do that, you have a branch, and create a legacy of shit for users.
The mature users will know the old way, and the new users will probably only know the new way.

The reality of this is, endless questions about why "it" does not work from the very same people who never read the readme.

This is still an interesting question though, can you please add some background as to why you'd want dcri in the pools.txt file?

Happy mining.

Hahaha, this made me laugh. (the question and answer too)
That would be WAY too long a discussion, and probably ultimately not worth it.
I wish my "problems" were as trivial as this, but regardless, one would think "good" might be some clue perhaps :-)

I wonder what the "real" question is here? Issues faced?

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.

It's VM, (doesn't exist :-), use what you want, but leave 25% free disc space.

48000 is stable on 13GPU in my testing.

Yeah, I spotted that also. Actually I was testing against 2 different pools, that test will wrap next Monday evening, (7 days).
This whole ETC thing just happened to popup in the last 24hrs, and right now, I don't have any spare rigs to run a proper comparative test, (but I am starting to sketch out that test).

Clearly pools have a bunch of algorithms to divide up the work, load balance, and match reported hashing power to jobs, I wonder how well that scales.
Obviously not all pools do that the same way, and in fact, doing that well SHOULD be a selling point for them, secret as it may be.

I'm assuming ethermine use more or less the same mechanism on their ETH and ETC pools, (another test :-)

But I'm going to try a 1:1 and 8:1 side by side next week on the ETC pool.
Will share the findings for discussion.


Side note: ETC has indeed dropped 6hr average below local hash rate, 14:30-ish UTC.
Happy mining everyone.

Ethermine performance with Claymore.

Hello fellow miners.
I'm currently running some 10 day comparative testing, two identical rigs, identical hardware, same number of GPUs etc, (more on that later), but as it happened yesterday another GPU arrived, and it happened to bring the overall gpu count to an odd number.

So as I didn't want to upset the comparative test by having 1 more GPU running on one rig than the other, I decided to start a second instance of claymore, (using only this single GPU), and so as not to mess up the graphs at ethermine, I targeting this single GPU at ETC.

What is interesting is, after 24 hours, and allowing for the 6h average to normalise, this single instance, one GPU, is averaging above my local hash rate, while ETH is consistently lower.


Now, by no means can any conclusions be drawn at this stage, but it got me wondering....

So, for the next test, I'm going to configure 8 claymore instances, single GPU each, and go head to head with the other rig, running one claymore instance with 8 gpu.

I'm wondering if/how/what ethermine is doing differently, that single gpu instance is local hashing at 32.15, rock solid, but the @pool average in the last 12 hours, 35.25~33.6MH/s. (plus 7%!)

While the other rig, is running at -4%

Have any of you guys experienced something like this, or can point me to previous comparison tests?

Cheers

For what's it worth, I totally agree.

It might have been profitable to dual mine in the past, and possibly still so if you happen to have free power, but I calculated I used about 35% more power.
Worse still, stability dropped, and you pull more power out of your PSUs, which probably pushes them away from optimum efficiency.

Furthermore, solo ETH, I can run 6x RX580 off a single 1000W PSU, and have it sitting at 91% efficiency, (down from 93%). (Costs me 2% loss over time, verses cost of another PSU. Long term, that 2% is going to add up, and 2% would surpass cost of another PSU, so it matters).

Dual mining, I could only run 4x RX580 stable. (I could start claymore with gser 2, with 5x RX580, but had a LOT of interruptions, crashes, freezes etc).

Conclusion: Factoring in 35% additional power consumption costs, plus a 33% increase in the number of PSUs I needed, (plus their losses, (7%) plus further drop in efficiency), it's very hard to see where you'd expect the payback to offset these added costs.

Then, as Jackbox astutely pointed out, you have to factor in the added stress, and reduction in MTBF.

Assuming you're located at higher/lower latitudes, through the winter, assuming you can swap out air, you save costs on cooling. Come summer, you're paying more for cooling. Dual mining was astounding how much hotter the GPUs ran, (last winter), come summer, your fans are working harder to cool.

More costs.

Cool and steady = stable = consistent revenue.

The added down time I hit dual mining, (a considerable loss in itself), was the knife in the back afaic  

It was worth the experimentation, conclusion was clear.
Far more good reasons NOT TO dual mine, and no good reasons for it.
At least in my experience.

Footnote: I made NO extra profit dual mining, even if I ignore the cost instability cost my ETH mining, comparing ONLY the additional power cost, I was loosing 3:1.
(Extra power cost $4, I earned about $1.2 from the other coin).

Revenue is not profit.

Nice going, thanks for posting a followup.
Happy mining.

BTW: I have also see Radeon settings revert some GPU to graphics after a hard crash.
It's a good plan to map your rig, (physically identify each GPU, and it's logical number in claymore), note what hash rate you expect from each gpu.
Monitoring in Eth manager is a good way to spot check if each GPU is performing.

One of the nastier things about the AMD drivers, is the hit your hash rate takes, if it reverts to graphics, (usually more than 30%), and if that wasn't enough, while you burn the same power!

If you swap a card to another slot, it will get a new pci bus address, (and this means, radeon setting will be back to graphics), but claymore is only counting from 0.

Suppose you have 3 GPU. (GPU numbers below, as per claymore)

GPU0 is on pci node2
GPU1 is on pci node6
GPU2 is on pci node7

You set all 3 to compute in radeon settings, and away you go.

Later, for whatever reason, (new card, bios change, swap out riser, cable etc), you move GPU2

GPU2 is now moved to pci node1, in claymore you will still see 3x GPU, but the addressing will be.

GPU0 is on pci node1
GPU1 is on pci node2
GPU2 is on pci node6

You only changed/moved one GPU, but this reorders the addressing, and while this won't impact claymore, (other than to confuse you perhaps), Radeon settings are ONLY using addressing on the pci bus, so for sure you will have to set compute mode for GPU0, (it will be graphics by default, as radeon detects it as a new gpu found, as it's on a newly used bus address).

This gets SUPER painful as you expand your rig.

I've been toying with the idea on my next build to, only add 1 single GPU, let radeon detect it, I can set to compute, shutdown, and move that single gpu to the next slot. Repeat, move, repeat.
That way, assuming the GPU make/model is the same, all bus nodes will have a "remembered" gpu/bus address, which is set to compute.

BUT all this takes a LOT of time, and with radeon settings as they are, this time increases exponentially with each GPU added.

What is SO LAME, is AMD do not, have not, added a SIMPLE install switch, to clean install drivers in compute mode, (graphics disabled), Hell, even Mr Claymore has managed that, what's AMDs excuse?
 
What bugs me, is how often this lame method to set compute mode is actually needed.

I really hope AMD make some improvements here, and my suggestion would be a installer switch

setup.exe /compute

Which tells the installer to install in only compute mode, rendering radeon settings, and graphics to compute mode redundant, and save LOADS of time and hassle for their customers.

I should add, that all the rendering farm customers would certainly appreciate that as well.

Good luck

Nice going, and thanks for taking the time to feedback results.
I was wondering about that nanopool address, it's possible they used eu1.nanopool.org:9999 previously, but have changed the servers/names and have various aliases. The problem with that can be, the routers in between, DNS cache and arp tables will have duplicates. This stuff is self healing, but can actually take days to settle down, and in the mean time, things, (like name resolution, routing etc) can take longer than expected, (expected as in, longer than the time out limits your end, or along the path etc), and as you're essentially on the far end of a long chain, all those "little" delays can add up, and the application will appear to hang your end, while in reality, it's just waiting.

Hopefully, setting the log to debug, you will see a bunch of additional entries, like "waiting... etc etc" if you don't see anything logging, then probably claymore is hung. (Don't forget, if you're using notepad to view the live log, you need to refresh/reopen it, to see new entries.
Hitting f5 in explorer, should show you the log file size increasing, is another method to determine if anything is logging.

(don't forget to disable debug log when you're stable)

Virtual memory. It's far from clear what claymore is doing with that, and although 16GB is the minimum, I'd suggest it's never a good plan to aim for the bottom!!
It's only VM anyway, set it as high as you like, (although to be safe, less than free space on disc, plus some headroom).
Suppose you have 100GB free, setting VM to 60GB should be pretty safe, assuming your rig is dedicated for only mining.

Ok, afterburner.
Less than ideal to use that imho, any application can crash, what damage can happen if afterburner crashes? I'd rather not find that out the hard way.

Did you spot in 11.7, Nvidia temperature control is now supported?
 added temperature management and overclock support for recent Nvidia cards in Windows: "-tt", "-powlim", "-cclock", "-mclock", "-tt", "-fanmax", "-fanmin" options are supported for Nvidia too.

I'd suggest using it. That way, if claymore crashes, (no more work is pushed to GPUs), and at least your GPUs revert to bios control, cool down etc.
Right now, if your afterburner crashes, and claymore carries on, you're going to potentially cook those cards, or force them to their hardware trip point, (probably something scary like 100C plus).

NOT GOOD.

Remember, mining is a bit extreme for GPUs.
Like anything engineered, they are designed for a purpose, and have a duty cycle to match.
It's not expected under typical use, that GPUs are running, flat out, 24/7, this means they will probably have a shorter lifespan than if they were used for gaming.

Render farms, (not so dissimilar from mining), are constantly swapping out/in cards, and usually have failovers and backup nodes to pick up the slack.

So the key here is stability, steady temperature control, depending on the fan type, probably constant rotation, speed regulation, rather than on/off/on is going to be preferable. Think of it like trying to avoid the extremes, and flatten out the peaks and troughs.

Mechanically, we have to consider these GPUs are getting hot! Parts are MUCH hotter than 100C, very reliant on cooling, and different materials expand/contract at different rates. Copper is one of the more extreme examples, but any such mechanical expansion is also going to reduce life, contribute to increase failure. It's the CHANGE, (expansion), that causes mechanical stress. Avoiding that as much as possible, will extend life.

If you're in this for the long run, ROI etc, then it's a good idea to consider these angles, and imho, get cards with a well engineered cooling scheme, active and passive, reduce voltages/current etc, set the upper cut limits lower, (e.g 98C to 88C), set a reasonably LOW target temp, (60C), if it means you work the fans harder, so be it, those are cheap to replace compared to a GPU.

(Find some stable settings, and customise your BIOS to reflect that). That way, if all else fails, the hardware will self protect.

Last advice, wifi.
I was amazed at how many instabilities evaporated when I switched that off.
Part of the problem is, these days, wifi routers are doing all kinds of (for open rigs, nasty stuff), like beam forming, and essentially flooding the space with microwaves, as are of course all the devices trying to connect, like phones etc.
In your typical PC, it's in a metal box, microwaves don't travel well through flat/sheet metal, and wifi antennas are OUTSIDE the PC case, (even in laptops, antennas are as far away from the motherboard  as possible.

Now we have open mining rigs, no casing, (shielding) and worse still, we have a LOAD of wire stands running all over the place. Cables from PCIe cards to risers, (should be shielded, but who knows), but also we have a lot of single strands, power lines to the GPUs, and normally ALL this stuff is further shielded inside a metal computer case. Furthermore, all components in there will share a common shield ground.

While microwaves, (and any "radio" band waves for that matter), well those LOVE single strands of wire, those being brilliant antennas, being it receiving or transmitting.

So, what all this adds up to is TROUBLE, when exposing open rig, no common ground, worse still, multiple floating grounds, multiple power supplies lots and lots of microwave sucking antennas.

As recently as 2 weeks ago, (after months of mining), I finally got around to hard-wiring LAN to all my rigs.
This comes after months of chasing down gremlins, timeouts, dropped sockets at pool, (while still having local internet access), random lockups, crashes, you name it, it's a long list, and a LOT of time.

I'd say, I'd fought hard to tune out 50~60% of events, reduced frequency for sure, but once every 7~10 days, I'd have a succession of dropped connections, resulting in stale shares down the line.

Since eliminating wifi, (and 1 rig on powerline LAN), I'm amazed at the difference, (and kicking myself, as I know better), I guess it had become a bit of a campaign, which with hindsight, was a lost cause :-)

What one needs to consider is, steady, steady, steady is the key to mining.
Eliminate as many of the potential risks to that, and you're set up to go steady :-)

Good  luck.
 

OK, here's the deal with blockchain drivers.
Beta release, driver specific for mining, but now kind of dated, and only support 8 GPU max.
Later drivers, (general release), include a new feature to switch between graphics and compute in the Radeon Settings gui.
(Check out the Radeon  release notes!)

Radeon Settings / gaming /Global settings, (select each GPU in turn, LAME AMD, utterly LAME!), select compute, confirm OK for restart.
After setting all GPU to compute, shutdown PC, reboot etc.
(I've seen on every radeon release, failures to mode change, and reboot will fix that).

Suggest you use 18.3.4

Been running that for some weeks, it's stable so far, and supports up to 13 GPU per rig.

Good luck.

Interesting, why the timeout 15?
Note, the exe string needs to be single line, no c returns, or line breaks etc.
Also, 2 things you could try on the problem rig.
-mode 1
-dbg 1

I'd try stripping that to the minimum, (also make sure you set your virtual memory to at least 16GB!!!)

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 eu1.nanopool.org:9999 -ewal wallet.rig/email -epsw x -mode 1


BUT.....I just checked, and it looks like nonopool servers are different to what you have above.

Should be

eth-eu1.nanopool.org

Are you 100% sure, the server you are using is correct?

Cheers

Hi there.
Make sure you unblock EthDcrMiner64.exe
(right click, general tab, check unblock, /ok)
Turn defender ON, and set an exception for EthDcrMiner64.exe
It can be useful to relax security while debugging, but it's bad form to ignore it forthwith.

I'd suggest you take a look at your log file.
I'm assuming you mean, claymore 11.7 was working before you updated windows, and you changed NOTHING else, drivers etc, cmiiw.
That being so, look at a previous log, (from when it was working), that will show your full init, through to mining, and then compare with your current log.
At some point, your current log will halt, if you line old/new logs up, you will see what SHOULD be happening next, and that is where you need to investigate.

Good luck.