Right now all of my miners stopped working (2g cards) is there some explanation, I tried reboot but same thing it doesn't work - OpenCL error -4 (0) - cannot create DAG on GPU
It's interesting that I have rig with 4 gpus all 2G and GPU0 works but the others - OpenCL error -4 (0) - cannot create DAG on GPU
Any ideas?
Just hit DAG epoch 90, so by default the miner will allocated enough space for epoch 92, which is the first DAG that is too large for 2GB cards. Try -eres 0. That should buy you 1-2 more DAG changes. Reality as we have always known, is that 2GB cards won't be able to mine eth anymore quite soon. |
|
|
|
|
Purchased an account from these guys, was already banned before I even tried to login.
Waiting to see if admin will replace or refund.
|
|
|
|
Windows 10 now detects v4.5 as a virus (Trojan), it deleted the file from my computer and when I try to download it again, it says: Virus detected... Is it safe to restore it?
Another typical false positive. Just exclude the directory. I wonder how many people this impacted - looks like network difficulty took a bit of a dive. |
|
|
|
Claymore - do you think further optimizations for fiji chips are possible? Memory controller usage seems to be sitting pretty low, and I get the feeling after playing with intensities that there's more room left for optimization.
It seems a higher ethi allows for increased decred hashrate without ethash loss. I am now pushing ~30MH/s ethash and 1650MH/s decred with ethi 20 and dcri 110. With ethi 16, dcri can't go that high without losing a chunk of ethash. Compare that to 30MH and under 1000MH/s decred max with lower ethi.
Wasn't ethi 16 the max? For my case the ethi isn't doing anything though, setting it to 8 or 16 doesn't affect a single thing. I thought claymore said 32 was max, but values higher then 16 cause very long kernel runtimes. |
|
|
|
sensors tab says..you cannot downlclock below 1500 or VRAM..
In that case you would have to flash gpu with modified bios and set memclocks in it (vbe7 and atiflash would be the easiest way). Or you can use the 15.7.1 drivers, where downclocking still works. Downclocking is broken (intentionally by amd?) in later drivers. From my testing, there didn't seem to be an advantage between 15.7.1 or 15.12 in terms of performance, but 15.7.1 lets me downclock ram and save on power for free. |
|
|
|
|
Claymore - do you think further optimizations for fiji chips are possible? Memory controller usage seems to be sitting pretty low, and I get the feeling after playing with intensities that there's more room left for optimization.
It seems a higher ethi allows for increased decred hashrate without ethash loss. I am now pushing ~30MH/s ethash and 1650MH/s decred with ethi 20 and dcri 110. With ethi 16, dcri can't go that high without losing a chunk of ethash. Compare that to 30MH and under 1000MH/s decred max with lower ethi.
|
|
|
|
i have this rig with 2x r9 390 and 1x r9 390x
using gpu-z monitoring (sensors tab), i OC all the cards 1120 clock and 1600 ram ...
looking at sensors tab only one card is at 1120 clock the rest are ~ 930 clock (i'm not sure which card is 390x coz gpuz labels them all 390)
therefore only one GPU is OC'ed...
all ram are at 1600mhz
graphics card tab at gpu-z shows uniform 1120 clock for all cards...sensors do not
any tips?
my 280x rig is uniform, all clocks matched.
edit: these issue occurs only in dual mining mode, mining in ETH only (-mode 1) shows uniform clocks in sensors tab of GPU-Z.
claymore..any suggestions? Sounds like down throttling, of course. If cards are getting too hot or drawing too much power, the firmware downclocks them. Why do you overclock RAM? It doesn't seem to offer any hashrate increase from my testing. In fact, on my R9 290 cards, I downclock VRAM to 1125mhz for increased power savings (with no hashrate decrease). I also find downvolting usually results in more stable hashrates, as the GPU is less stressed and is more likely not to throttle. |
|
|
|
Something seems odd about decred payouts, like they are short about 15%. e.g. http://zpool.ca/?address=1Av5gw4wuRCgAfuw7Yinwze65vA8unzvv917.987 DCR block (9hr ago), percent was 6.7222% = 1.21DCR. But, paid only 1.02DCR (15% missing) 18.101 DCR block (10hr ago), percent was 5.7444% = 1.0397364. But, paid only 0.885760 DCR (15% missing) What's happening here? |
|
|
|
This may be a little sophmoric for this discussion about the attributes of Claymore's Dual Purpose Miner, but here goes: Currently using linux for ETH mining. Should I load Windows to an 16gb SSD and boot off, then download the DP miner? Or maybe can I just boot Windows off of an 1TB HDD that I own already, add DP miner then proceed? Don't know if using the HDD to would affect performance making it not worth?
Since v4, hard-drive isn't even used to store the DAG, and even when it was, disk speed didn't really matter. I would guess that 16GB would probably be too small for Windows. lol configurations are exactly the same. And the fee you refer to is 1% on both. This miner is free-to-use, however, current developer fee is 1% for Ethereum-only mining mode (-mode 1) and 2% for Ethereum+Decred mining mode (-mode 0), every hour the miner mines for 36 or 72 seconds for developer.
Decred is mined without developer fee. You realize that says 2% fee only applies to Ethereum, right? There is no devfee for decred mining. |
|
|
|
SO with no more DAG files needed then how does this effect the hash speed as thing move on as bigger DAG files use to get less speeds use to get. So does this mean should see a improvement in speeds from cards when DAG use be smaller on size n bigger on hashes ?
v4 doesn't change anything about how the DAG is used, just how it is generated and stored. The dagger working set will continue to grow each epoch, and if your GPU slows down more because of tlb issues as the dag grows, it will still do that. Before, the CPU would calculate the DAG, it was stored on the hard drive, and transferred to the GPU memory over the pci-e bus. Now, only the dag cache is pushed to the GPU, and the DAG is generated on the GPU (and never stored on HDD or in CPU accessed RAM) and only stored in VRAM. In short, it's a bloody awesome improvement! -- @freeapp that sounds right if you're using dcri 100. Dcr mining is a "bonus" in between ethash gpu usage when it's busy with vram accesses. Values between 20 and 40 seem optimal for different GPUs and result in the same or increased ethash performance with moderate decred performance. |
|
|
|
Another feature that i'd like to suggest is a way to for us to identify which card on a rig relates to the GPU number. The only way I can think of doing this would be, for example, if you hit CTRL+0, then it will adjust GPU#0's FAN to 100% while adjusting all other GPU fans on that rig to 5% for 15 seconds, that way we can know that GPU0 will be the card on the rig thats running the fans at full speed. This would be a huge help with troubleshooting hardware.
Can second this - GPU ordering is totally wack in this miner. GPU-Z, Afterburner, etc seem to show the GPUs in a totally different order. |
|
|
|
So i tried moving some other machines over to dual mining and having alot of problems with the 3.2 version
several machines will just reboot them selves while mining the dual alogos, no error message nothing. I wiped one machine with 6 290x cards back to stock windows 10 default drivers 15.300 ( always gets installed no matter what i do, even if i turn off network and mnually install 15.12 crimson when i check the device i see 15.300 /shurg one machine with that same driver works fine in dual mode)
tried default intensity 30 and higer same deal machines just randomly die after about 10 mins
any ideas ?
Don't use win 10... problem solved  Windows 10 works perfectly fine. Marvell1's problem sounds like power, excessive overclock, or similar. |
|
|
|
Still getting around 10% rejection on DCR/Suprnova. Don't know if its miner's fault or Suprnova's. Can someone recommend a good DCR pool?
Problem solved as soon as I made the switch to Stratum.
Is the only stratum port for suprnova diff 1 or am i missing something? Yup. Not missing anything. The only DCR pool I have tried with working vardiff is coinmine. Diff 1 with stratum works fine tho, just excessive load on the pool servers. Pool.mn says they have vardiff, but it doesn't actually. |
|
|
|
finally it runs with coinotron.
But after 1:04h run time the miner finds instead of green "share found!" only white "outdated share found - skip"
what does this mean?
Result for me after a few hours (R9 Nano): more GPU load, more heat, same hashrate. And repeated "outdated share found - skip"-messages. Under these circumstances, no advantages and so I return to feeless genoil. I think optimisations for Fiji cards are still a todo. Claymore's last major release mainly improved slower cards. |
|
|
|
with stock clocks?
i dont think so
Yes, it says 2.5Eth at stock clock hashrates (for 15x 290), but you should earn about 5Eth. That calculator is totally wrong. With overclocks, it's closer to 6Eth. |
|
|
|
That calculator is completely wack. You should get double the Ethereum output that it suggests. |
|
|
|
|
For anyone interested, I am having best results/profitability on my R9 290 rigs with:
- AMD 15.7.1 Driver (only _extract_ installer package [do not install], load drivers thru Device Manager) - allows downclocking and results in the least GPU usage dips.
- Copy amdocl64.dll from AMD 15.12 to miner folder - brings up hashrate _very_ slightly
- Stilt's mining BIOS for 290 - lower power usage and slightly higher hashrate
- Downclock memory to 1125 (lower timing strap, results in the same performance as 1250 with lower power consumption)
- Overclock core as far as is stable (I use 1080mhz now; used to use 1100, but with increasing ambient temperatures have pulled back to 1080 for stability)
- decred intensity at 33 (lose ~300Kh/s Ethash in return for 50MH/s decred)
With version 3.2, I am getting ~0.5% DCR rejects, and essentially 0% Eth rejects.
31MH/s on Ethash and 500MH/s Decred for each GPU.
Ethereum pool effective hash is ~3% below reported (makes sense given tiny GPU usage dips and 2% devfee).
Best part is the stability.
Keep rockin' Claymore!
--
Claymore: Can you please add the share timer to rejected shares too?
--
revelacaogr/Lucky - Luciano: pool.mn doesn't actually have vardiff, their page header is lying. Their stratum just stays at diff 1 permanently. Only site with working vardiff I've seen is coinmine, but their reject rate is pretty bad from my testing.
That said, I'm using pool.mn right now as the profitability and reject rates have been the best.
|
|
|
|
|
Claymore is the man. Thanks for addressing my 2 requests so quickly.
Edit: can you add the timer output to rejects too?
Only thing this miner needs to be perfect now, IMO, is failover support.
Also, DCR changes seem to have had a positive impact on rejects. I'm under 0.5% rejected shares now (need to test for longer, ofc, but looks great).
|
|
|
|
A bit strange approach, is not it? Just send worker name as second param and it would work like a charm.
Eth's mining methods are more then a bit strange (and inconsistent between every implementation), indeed. 2 requests (fairly trivial I think): - show eth/dcr when printing Authorized - show response time in ms for work submition and response e.g. Share Accepted (80ms) |
|
|
|
|
Show Posts
