Topic: Claymore's CryptoNote AMD GPU Miner v11.3 - page 218. (Read 2145062 times)

Just use 13.12 then.

no effect

Try to add this to .bat file:

setx GPU_FORCE_64BIT_PTR 0

I use catalyst 14.9 + miner 9.1 for 14.x cata .. i see message in start (warning: Linking two modules of different data layouts x5) later miner work.. hashrate on pool normal, maybe can not pay attention to this warning?

Try reading/searching the thread you're posting in before posting a question:



So... first make sure you're running 13.12 drivers, and the 13.12 miner.  Then if that doesn't help, try setting the GPU_FORCE_64BIT_PTR environment variable.

Hello

Say please message below problem or i can work ?

warning: Linking two modules of different data layouts

I've used -2 and while it used to produce relatively similar hashrates at less power, it produces almost identical hashrates of -1 or -4 and the power consumption is almost identical using a kill-a-watt meter.

I wasn't asking about the current version though, I was wondering if Claymore was considering working on power consumption.

As I wrote above, the logs look totally normal up until:
remove first packet -1

And that is always the last line in the log when this happens.  You see tons of other "remove first packet" lines before, but all list positive numbers.  Without ever seeing the code, I would wager that null/false/-1 is being returned somewhere.

Curiously, on my R9 290s running the STILT's custom mining, the -a 2 "low power consumption mode" actually produces slightly better hashrates, that are MUCH more stable, AND drops the power consumption.

Pretty cool, mining XMR is actually profitable vs power right now for me.  Cheers to Claymore.

Power usage is the same as before.

PM me the log, I'll check it.

Hey good question, I think the code could be improved.

Putting aside hashrate increases, is any work being done to reduce power usage / increase efficiency?

V9.1 and V7 both segfault on my gentoo machine with v13.12 drivers.

It mines for a seemingly randomly amount of time before this happens (typically 3-10 seconds).

dmesg snip:
[   40.414308] miner[3190]: segfault at 204a000 ip 00007f6bd45223a6 sp 00007f6bb5ffa288 error 4 in libc-2.16.so[7f6bd43ed000+19e000]
[  105.256506] traps: miner[3226] general protection ip:7f60d85f54e7 sp:7f60b3ffe060 error:0 in ld-2.16.so[7f60d85ec000+22000]
[  122.109788] miner[3245]: segfault at 204a000 ip 00007f7d652053a6 sp 00007f7d2bffe288 error 4 in libc-2.16.so[7f7d650d0000+19e000]
[  145.624938] miner[3268]: segfault at 204a000 ip 00007fbf96ace3a6 sp 00007fbf5bffe288 error 4 in libc-2.16.so[7fbf96999000+19e000]

Logs always show this last before the crash:
10:38:50:408    ea7fc700        Share accepted
10:38:50:408    ea7fc700        remove first packet -1

I presume -1 is an error, because normally this is a positive numeric value.

---
Update/edit:
I switched to another pool, and I haven't seen a segfaults yet.  I was initially testing with backup-pool.com with very low starting share target.  There's definitely a bug in the miner causing crashes, but it seems you can mitigate it (or at least, cause it to occur significantly less frequently) with higher share targets (less shares sent/received).  backup-pool on a higher starting difficulty port is running for 15min now.

Re-installed amd drivers.  Problem fixed. Thanks

I used the Dependency Walker and found that IESHIMS.DLL and GPSVC.DLL are missing.  I recently unistalled some nvidia drivers that I dont use so maybe this is the cause of these missing dll?
I am scanning the computer for viruses etc.  Later I will uninstall and re-install the amd drivers to see if this fixes the problem.
Thanks

1. Make sure you don't use any proxy or pools that remove dev fee, check readme for details.
2. Try some other big pool.
3. If pool supports fixed diff, set it to 10000-20000 and see hashrate on the pool. Many pools set very high target diff to reduce server load, for example 250000. Such high target means that miner will send shares very rarely, for example, if your hashrate is 2KH/s it will take >2 minutes to find a share at 250K target diff. Pool calculates hashrate within some time, at too high target diff this time is similar to average time to find share and becomes inaccurate, as result sometimes you see low hashrate and sometimes you see too high hashrate, it depends on miner luck for this time period.

Usually this error means that Windows cannot start application because some required DLL is missed. Miner does not require any specific DLLs, you can use Dependency Walker to see what DLLs are required:
http://stackoverflow.com/questions/10492037/the-application-was-unable-to-start-correctly-0xc000007b

So, I'm curious, why would my hashrate fall poolside since 8.0? With 9.0 it went down a little bit, and a little bit more with 9.1... Now it's no where close to what I was getting a month ago. The miners show hashrates about 30% higher then what the pool does, I'm mining on dwarf pool as well.

Can anybody convert this to gui miner for me because i am yet to understand the settings for other type of mining.

Dear Claymore:

Out of the blue my miner stop working version ClaymoreCryptoNoteGPUMinerv61Beta
An error window pops up and says NsGpuCNNMiner.exe application error  The app could not start correctly (0xc000007b).  Click to accept and close the program.
I am sure something change in my system but dont know what.
win 7 16 GB ram i7 950 cpu
amd r9 280x  with 14.9 catalyst.

system had been working for 1 month without any problems...

I can run the cpu miner OK but my GPU will not run..  I can mine x11 with same gpu and sgminer_v5_0_mod without any problems, so gpu is ok.

I updated to new version 9.1 but the same error appears.

Thanks for your help