Topic: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v15.0 (Windows/Linux) - page 237. (Read 6590718 times)

I'm all of a sudden getting
"OpenCL error -4 (0) - cannot create DAG on GPU"
With Claymore 11.7

What is this error again? It's been so long since I've had to deal with it.

EDIT: Nvm, I doubled the pagefile and it's fine.

Claymore, first of all, thank you for all your great miners! I've been using them for a while, for various crypto currencies, and this software must be the one a lot people have been expecting the most. And my rig always get it's best perform if using this software. And again thank you.

Can you share what you're putting in your start file?

Seems to me like you're trying some miner's integrated over-clocking or under-volting features and the numbers which you're putting there are out of limits/reach of your graphics card.

Just now , first time to see rejected share in my rig since the beginning i used claymore..
I've got 2 rejected shares now..

FYI, did not touch or configured anything..

It is a weird day!

Try to increase pagefile size. Drop overclock/undervoltage to stock values. Uninstall drivers with DDU and install them again.

Any idea what's going on here?
All of the sudden, my miner doesn't work anymore...

Thanks iSuX, I'll have a play when I get a chance. Everything is stable, but I know I should be able to get more out of these cards. But of all the OC tutorials, none mention extra straps. But I know there are bunch of other variables to work on as well (PSU, motherboard (that's a whole other question), mem types)

No worries, but to be clear, Claymore has no dependency on sharing. (Equally, sharing is a weakness in your system security).
This sounds more like a windows folder permissions issue.
Assuming YOU don't have the need to share that folder, (and knowing Claymore does not), you might like to check the next tab over to the right, (from sharing).
Right click the folder > Properties, (security tab), and grant your (normal) windows user account, (read & execute), or even full control.
At least that closes a potential security weakness, (sharing), and also should solve this appropriately.
Happy mining

I don't know how you're make it, but my system updates to 1803 April Update about month ago. I used 18.3.4 Adrenalin driver. I tried to update it to 18.4.1 driver and encountered many bugs with miners.
I installed back 18.3.4 and miners start to work normal. Now I installed 18.5.1 driver and all Claymore miners works normal.
Now I have 1803 Windows 10 with April Update and 18.5.1 Adrenalin driver. Claymore miners works with the same effectivity as on 1709 with 18.3.4.
My cards is several RX 580 8Gb and 270X 4Gb.

EDIT: At this moment Claymore 11.7 dual miner works on ethereum mining allready 13 hours and 51 minutes without rejectes and incorrect shares. It's very strange... Usual for this time I have several rejects and incorrects...

Thanks for your help.. The folder needed to be shared weird but works now.

Claymore 11.7 seems to be a tad more sensitive to overclocks.

To be clear, claymore does no such thing!
All claymore is doing is "sending" the clock value YOU specify, that is all, nothing else.

If it fails, your clock setting is wrong, or you're working too close to the limit of your hardware.

What has changed/improved over time  in Claymore is ability to leverage more from the hardware, so if you're cutting it too fine, or dual mining, you might tip it over the edge.

But regardless, claymore has no such "sensitivity", it simply does what you ask of it, and you need to ensure that is rational for your rig/hadware.

Hey there, sorry, I'm not suggesting you use the console every time, just one time, so you can read the output.

BUT: If you are saying, for example, your desktop shortcut to your batchfile executes and closes, yet opening a console and executing the batchfile works, claymore starts Mining etc, then that is probably a windows permissions or security settings, thing, or possibly your antivirus related problem.

But essentially, if the console execution is working ok, that proves 99% is ok, os, drivers, batchfile content, claymore, etc etc.
So if you have a shortcut init fail, you can shift focus away from the above.
Cheers

Updates, sigh.
Well, OK...
You have 30+ miners? WOW, so this should be well within your means to solve.

First: Work out if you have a hardware problem. (Take one/some of those problem GPU to a good rig and test)
Given you have 30+, I assume you long ago recognised the absolute necessity for a dedicated development/testing rig, so use that one, which of course you would NEVER update, if you expect it to act as your benchmark. ;-)

Check my post on power supply cables, I mention this, as it's easy to waste time thinking only about the stuff you most recently changed, and back track from there, but if the rig was off for a while, during updates, and subsequent issues, it's not impossible you have other problems, hardware related set of some time bombs etc.

I'd suggest not wasting time, and MAN that wastes time, on anyone using the Aug 2017 blockchain drivers, certainly not for purposes of troubleshooting, they are beta after all, and specifically tagged as not stable/released.

But to be clear, make sure you eliminate the hardware before expending time on the software.
(You could also pull all GPU from that rig, drop in a known good GPU, riser, cable etc), and see what that reveals.

All the more easy when you have as much hardware as you have.

If you're 100% certain the hw is ok, set log to debug, see what is going on before/after the hang event
Hope you get some sleep too.
Good luck man.

Thanks yes I am familiar with console.. Annoying that I gotta use it for 11.7..... What is the advantage of 11.7 over 10.6? Thanks for the help BTW

Did you read my post? My rig has 6 rx 570. Win 18.03 didn’t like one of the cards. It wouldn’t boot with that card plugged in. I tried the latest driver and the block chain one to no avail.
I reinstalled win 16.09 I think and problem solved.

I'd suggest taking a look back through your logs, and assuming you changed nothing your end, if this worked before, it might be explained by the pool being unavailable, or unreachable.
Which of course is exactly what that is saying, so the question is why?
Maybe try pinging that address, or pasting the relevant sections into your browser, check if it's up etc.
Good luck man.

Hi jeremyismer

You ask an interesting question, and are probably already thinking on the right track to solve your problem.
I've been thinking about blogging here on this topic, so thanks for the inspiration. Apologies if this is a bit off topic/Claymore. (it IS, but the question is here too).


I can't claim to have the definitive answers, or even if this is "the" way to do it, but I can share what I discovered along the way, trial and error methods etc.

What I noticed was, some cards have memory timings stopping at 2000 while others go to 2250.
This seems more dependant on the memory type, than the actual card vendor or model.

For example, Micron memory based cards, straps top out at 2000 on (most of) my cards, and these were the worst performers out-of-the box, but one click timing actually made them worse in some cases.

What I think is happening in the firmware, is when an application/os is calling for a specific clock, (that is not specified in the table), the firmware is calculating that, (changing it), based on the scale/gradient as defined by the stepping and values in that table.

For example, (simplified), suppose the top strap was 1000 and has a timing value of 100, and the application calls for clock of 1010MHz, the actual value would be scaled up to 101.

So, when people start editing those straps, you have to think about how the firmware is going to be able to scale those strapping values, when you request some clock value that is NOT specially listed in the table.

What I see is a lot of data out there, where people are editing, sometimes only the top strap, sometimes the top 2, 3, or even 5.
Where that seems likely to screw up later on, will be with people trying to get every last single MHz out of it, and essentially requesting values that might not get scaled to something the card can actually deliver, or potentially values that don't parse.

On tuning straps/mem type.
Samsung: I've more or less given up on. It's a great performer out of of the box. All my efforts to increase MH/s were marginal in that respect, and questionable in stability. Ergo, I decided the potential gains were not worth the downtime. Time I can be using for those cards to mine. (Plus I only have 2 of them, so collective gain is not an incentive for me).

Micron: This is my top performer, but was a lot of work and learning. But all those cards hash at a super stable 32.64 MH/s  I shuffled 8 into a single rig, and sometimes think ethman is not refreshing, because those values change so little. lol.

Hynix2. I have to confess, I'm not so happy with my results, and am working on that. (32.07 is my super stable average)

It's tough man, you know, you struggle through issues get things working, take a breather, (if you're lucky ;-) let some time pass so you can assess stability, while all the time wondering, should I try to improve hash rate? What will that cost in down time, stability?

It's a question of expectation, so I decided early on to numerically quantify expectation, in hash rate terms.

I settled on  my absolute minimum acceptable on the RX580 would be 32.0, and I mean SOLID, never seeing a 31.999 for example.
(Claymore also helped me here, as his miner got faster, so I wouldn't claim all the credit there)

So currently I'm in two minds with the hynix cards, evening pulling one into the dev rig, I need some ROI :-)

Ok, so back to practicalities here.
I'm usually pretty hesitant to get involved in posting about BIOS settings, there is potential there to damage or even destroy hardware, and that would not be nice for anyone.

Also, I'm frequently astounded at how poorly some people follow instructions, even when those are crystal clear, and include advice to read it and ask first, if you don't understand.

Of course, that's not directed at yourself, simply a general observation.
So, blah blah "I take no responsibility, blah blah", you get the point.


OK, so have a think about this from a different perspective.

The firmware architecture is such, that we see a stepped scale.
If one requests a MHz value that is specifically defined in that table, THAT strap value is used.
Every other value, will be scaled/translated to something in between, (interpolated), or if set above the top step, extrapolated.
Now, interpolation is going to be more likely to work, as it's always constrained, but not so extrapolation, that can only follow the gradient as crafted by the steps between the lowest and highest step values.
Ergo, any value you set above the top step, is less likely to work, and the probability of failure increases with higher values.


So once I theorised this, I decided to test that theory.
I took the 300MHz strap value, and set all values in the table to that value.
Expecting the following: No matter what value I requested between 300 and 2000, there would be no change in hashrate, because there was no scale/gradient in that range. (flat line etc)
This proved so.
I then changed this, so-called flatline BIOS ver, so only the 2000 value was default, and when I requested 2000, I got stock hashrate, while 1900 was more or less the same as 300, (a tiny big higher).
Try to visualise that on a graph, and it makes it's pretty obvious what is going on.

So, essentially one could, in theory, have claymore pick ANY number for the clock, 9000 for example, and provided 9000 limit is set, and 9000 has a specific table entry, that would at least be accepted, assuming the actual strap value was something rational  like the original 2000 value.

It's kind of a lookup table, or transform table if you like.

Where I think most people screw up, is by flashing BIOS they downloaded from the net onto their cards, who knows what that does, every situation would be more or less unique, while perversely those same people probably have some "standard" expectation, (as do we all), but how does one expect standards, when working without a standard logical methods?
(That said, I looked at  LOT of those online BIOS while trying to work out what was happening in the firmware), so in that situation, having a bunch of random BIOS edits was useful to analyse.


The next screw up, is if you are going to edit a bunch of strap steps, you should at least start by using one of those specific clock values, and take it from there if expectation is not met.

OK, so, something else to think about.
That table is stepped, each line has some Id, (not visible in the editor), so you can't simply add additional steps in there, well, you can't with any editor I have seen so far. This means you need to edit an existing entry, and those are sorted by the ID only, so you can't for example think, "oh, I don't think I need the 400MHz step, as I have 300 and 800, so I will change the 400 entry to 2250.
Rough example, that table would then be
200
2250
800
1000
1600

But think about what that does to the curve on the graph. Fine if you use any of those specific values, but everything else would be a roller coaster value around the 2250 mark.

Also, you need to think about how the card inits, so I decided it would probably be a bad idea to touch the lowest value, (200, 300 etc), that is the stepping the card will init at, as it uses minimal power, and equally, if it gets a reset from the driver, it needs to start there before clocking up.

What I did was to edit the scale so I could make the last entry, (the fastest one), some value that was overclocked. I decided to pick 2250 on the RX580, simply because I knew it could be called, and meant I didn't need to test how to, (or even if), the MAX limit was editable, (and understood by the fw).
Logic being, minimal change = maximum stability.

Of course this means eliminating one of the lower, existing steps, and shuffling the rest of them up the list, which is kind of tedious in the editor tbh, and VERY easy to make mistakes, copy/pasting etc

The method I came up with is this.

Open 4 instances of the editor.
1: The stock BIOS for that specific card, (readonly etc, for reference and cross checking, typos or my screw ups)
2: The stock BIOS for that specific card, (same as above), but this will be the one I edit.
3: The previous revision (if I have one)
4: The BIOS with the straps I'm copy from, (if I have one)

Eliminate distractions, interruptions, and lots of coffee if it's dark outside :-)

Well, that's more or less where I'm at with trying to understand this topic so far, but work continues for sure.
The aspects mentioned here, where I devised tests for proof, I've said so, but I'm open to debate on, (or anything I might write for that matter), but I decided I was confident enough in that proof, to move forward.
Indeed some of this is purely theory, albeit observational based, but also based on more than a few years experience in related fields, and I'd very much welcome anyone correcting me if I've erred anywhere.

Equally, testing was done on Sapphire, Gigabyte, Asus based, RX580 8GB cards, which is hardly runs the gamut, so I would make no claims this info applies to all and every vendor, model. That said, there is enough above, people can experiment on their own, and take full responsibility for doing so.

@jeremyismer    If you want to PM me, link/dropbox/etc your stock BIOS and best edit version, I can take a look, (include card make, model of course), I might be able to help you in a positive direction.

Oh yeah, and here's a funny discovery, (that helped me understand more about the types of chips/archecture used, (you can Winflash the BIOS on a card, WHILE MINING with it in claymore) hahaha.

Happy mining everyone.

I have a 560 rig with windows 10 updated, if I switch to cryptonight and then back to ethash sometimes it will not work even after a reboot, I need to fully power off the rig and cold boot.
You also might have a card(s) with the mem clock too high, trying downing them by 10 mhz at a time.
Claymore 11.7 seems to be a tad more sensitive to overclocks.

Guys,

I have one miner that i cannot figure out. Mind you i have 30+ but yes i cannot figure this one out, and its driving me nuts.

The issue is that after the Windows 10 April update the miner will start but pauses....it does not close. I have tried everything i know and nothing. So i went ahead and installed a clean version of 1709 build with all of its updates.

I have reinstalled 11.7(which was working with no issues prior) and still nothing. I have tried adrenaline 18.2 and even downgraded to the blockchain drivers and still nothing. The motherboard is up to date, windows sees all the cards...no issues there. I have patched the drivers...etc...etc...

These are AMD RX560's that have been modded...and again these were working fine before the darn update got me.....I have also excluded the claymore folder in defender, set a pause for 30 seconds etc...

Im hoping someone out there has run into this prior....i am now having this same issue with another rig running rx470's

Any help would be appreciated

Thanks

Don’t ever use the April update. Just did a clean install only to find that windows wouldn’t boot to the desktop with both AMD 18.5 and the August blockchain driver. Wasted 3 hours.