Author

Topic: Claymore's ZCash/BTG AMD GPU Miner v12.6 (Windows/Linux) - page 142. (Read 3839201 times)

newbie
Activity: 23
Merit: 0
Using R9 280X with modded bios and some overclocked GPU. v12 works fine. Tested over 2-3 days working without issuies.

With v12.1 only 1st intensity is most stable. With any other intensity miner after about 10 min starts to show 0 hashrates and 0% GPU load.
With 1st intensity miner works normal 20-30 min and then speed is 0 too. Miner restarts and so on.

Returning back to v12. It's stable for me.

Windows 10 Pro.
Tryed 15.12 drivers, disable overclocking. Nothing helps.
Any other miners works fine. PSU 60-70% load.

After some couple of days testing, i find 16.3.2 drivers performs better in terms of stability than 15.12,
on all my 7970/280x/380/390 rigs...
And it happens on v12.0 and v12.1 miner ... (got some strange instability with 280x rigs, and tried 16.3.2,
everything works perfect so far).

b.r.
Alex
Thanks! I'll try 16.3.2.

P.S. Are you tried other WHQL versions like 16.12.2, 16.9.2, 16.7.3?
im using 16.10.2, and its fine, tried 16.12.2 and no success....
sr. member
Activity: 1484
Merit: 253
Using R9 280X with modded bios and some overclocked GPU. v12 works fine. Tested over 2-3 days working without issuies.

With v12.1 only 1st intensity is most stable. With any other intensity miner after about 10 min starts to show 0 hashrates and 0% GPU load.
With 1st intensity miner works normal 20-30 min and then speed is 0 too. Miner restarts and so on.

Returning back to v12. It's stable for me.

Windows 10 Pro.
Tryed 15.12 drivers, disable overclocking. Nothing helps.
Any other miners works fine. PSU 60-70% load.

After some couple of days testing, i find 16.3.2 drivers performs better in terms of stability than 15.12,
on all my 7970/280x/380/390 rigs...
And it happens on v12.0 and v12.1 miner ... (got some strange instability with 280x rigs, and tried 16.3.2,
everything works perfect so far).

b.r.
Alex
Thanks! I'll try 16.3.2.

P.S. Are you tried other WHQL versions like 16.12.2, 16.9.2, 16.7.3?
newbie
Activity: 17
Merit: 0
Using R9 280X with modded bios and some overclocked GPU. v12 works fine. Tested over 2-3 days working without issuies.

With v12.1 only 1st intensity is most stable. With any other intensity miner after about 10 min starts to show 0 hashrates and 0% GPU load.
With 1st intensity miner works normal 20-30 min and then speed is 0 too. Miner restarts and so on.

Returning back to v12. It's stable for me.

Windows 10 Pro.
Tryed 15.12 drivers, disable overclocking. Nothing helps.
Any other miners works fine. PSU 60-70% load.

After some couple of days testing, i find 16.3.2 drivers performs better in terms of stability than 15.12,
on all my 7970/280x/380/390 rigs...
And it happens on v12.0 and v12.1 miner ... (got some strange instability with 280x rigs, and tried 16.3.2,
everything works perfect so far).

b.r.
Alex
newbie
Activity: 23
Merit: 0
-i 1 seems to solve the hang issue for me...
For me -i 1 solves the problem too, but speed is less then -i 5 with v12.0. -i 2 gives the same speed as -i 5 in 12.0 but hangs often...
sadly after 3hours got a hang with -i 1 in 12.1....using 12.0 with -i 2 it is totally stable...i'm using agressive undervolting with my 7990s and 295...
newbie
Activity: 52
Merit: 0
I have two computers each with two cards (R270 now getting 172 H/s).  One runs windows 10 the other ubuntu 14. These have been running fine on 11.1

After upgrading to 12.1 I saw about an 11% bump in h/s.

Windows runs fine but the linux box is restarting claymore every 3 to 20 minutes. It is using crimson 15.12 driver (fglrx-15.302).  There appears to be some issue with OpenCL.  I tried "-i 1" and "asm 0" but no change.  Is there anything else I can try?

12:31:10:922   7a7a2780   GPU 6 temp = 63, old fan speed = 80%, new fan speed = 80%
12:31:10:930   7a7a2780   GPU0 t=69C fan=60%, GPU1 t=63C fan=80%
12:31:10:930   7a7a2780   em hbt: 1, fm hbt: 24,
12:31:10:930   7a7a2780   watchdog - thread 0, hb time 270
12:31:10:930   7a7a2780   watchdog - thread 1, hb time 402
12:31:10:930   7a7a2780   watchdog - thread 2, hb time 133
12:31:10:930   7a7a2780   watchdog - thread 3, hb time 5
12:31:10:930   7a7a2780   watchdog - thread 4, hb time 63268
12:31:10:930   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 5, hb time 62960
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 6, hb time 63134
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 7, hb time 63397
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   OC v5, Reset control for GPU 0, close miner right now if you want to use default control from Catalyst
12:31:10:932   7a7a2780   OC v5, Reset control for GPU 6, close miner right now if you want to use default control from Catalyst

try -ethi 8 and -wd 0

turning off watchdog was not helpful.  When the communication to the card stops, it just says to restart the miner.  I could add -r 1 with a reboot.sh but I don't see a difference compared to just enabling the watchdog.

ZEC - Total Speed: 172.517 H/s, Total Shares: 98, Rejected: 0, Time: 00:12
ZEC: GPU0 172.517 H/s, GPU1 0.000 H/s
ZEC: 02/25/17-11:50:24 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (159 ms)!
ZEC: 02/25/17-11:50:25 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (158 ms)!
GPU0 t=74C fan=100%, GPU1 t=57C fan=80%
ZEC: 02/25/17-11:50:41 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (158 ms)!
ZEC: 02/25/17-11:50:43 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (159 ms)!
ZEC: 02/25/17-11:50:46 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (159 ms)!
ZEC: 02/25/17-11:50:58 - SHARE FOUND - (GPU 0)
ZEC: Share accepted (159 ms)!
GPU0 t=73C fan=100%, GPU1 t=51C fan=80%
WATCHDOG: GPU 1 hangs in OpenCL call, you need to restart miner Sad
WATCHDOG: GPU 1 hangs in OpenCL call, you need to restart miner Sad
WATCHDOG: GPU 1 hangs in OpenCL call, you need to restart miner Sad
WATCHDOG: GPU 1 hangs in OpenCL call, you need to restart miner Sad
WATCHDOG: GPU error, you need to restart miner Sad
ZEC: 02/25/17-11:51:27 - SHARE FOUND - (GPU 0)
sr. member
Activity: 1484
Merit: 253
-i 1 seems to solve the hang issue for me...
For me -i 1 solves the problem too, but speed is less then -i 5 with v12.0. -i 2 gives the same speed as -i 5 in 12.0 but hangs often...
newbie
Activity: 52
Merit: 0
-i 1 seems to solve the hang issue for me...

It was already set to -i 1
newbie
Activity: 23
Merit: 0
-i 1 seems to solve the hang issue for me...
sr. member
Activity: 1484
Merit: 253
mettalmag, -ethi option is for Ethereum miner, not for Zec. Maybe you mean -i option. But if enable maximum intensity without watchdog eneabled function miner just stops mining without restarting when hangs.
legendary
Activity: 1084
Merit: 1003
≡v≡
I have two computers each with two cards (R270 now getting 172 H/s).  One runs windows 10 the other ubuntu 14. These have been running fine on 11.1

After upgrading to 12.1 I saw about an 11% bump in h/s.

Windows runs fine but the linux box is restarting claymore every 3 to 20 minutes. It is using crimson 15.12 driver (fglrx-15.302).  There appears to be some issue with OpenCL.  I tried "-i 1" and "asm 0" but no change.  Is there anything else I can try?

12:31:10:922   7a7a2780   GPU 6 temp = 63, old fan speed = 80%, new fan speed = 80%
12:31:10:930   7a7a2780   GPU0 t=69C fan=60%, GPU1 t=63C fan=80%
12:31:10:930   7a7a2780   em hbt: 1, fm hbt: 24,
12:31:10:930   7a7a2780   watchdog - thread 0, hb time 270
12:31:10:930   7a7a2780   watchdog - thread 1, hb time 402
12:31:10:930   7a7a2780   watchdog - thread 2, hb time 133
12:31:10:930   7a7a2780   watchdog - thread 3, hb time 5
12:31:10:930   7a7a2780   watchdog - thread 4, hb time 63268
12:31:10:930   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 5, hb time 62960
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 6, hb time 63134
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 7, hb time 63397
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   OC v5, Reset control for GPU 0, close miner right now if you want to use default control from Catalyst
12:31:10:932   7a7a2780   OC v5, Reset control for GPU 6, close miner right now if you want to use default control from Catalyst

try -ethi 8 and -wd 0
newbie
Activity: 52
Merit: 0
I have two computers each with two cards (R270 now getting 172 H/s).  One runs windows 10 the other ubuntu 14. These have been running fine on 11.1

After upgrading to 12.1 I saw about an 11% bump in h/s.

Windows runs fine but the linux box is restarting claymore every 3 to 20 minutes. It is using crimson 15.12 driver (fglrx-15.302).  There appears to be some issue with OpenCL.  I tried "-i 1" and "asm 0" but no change.  Is there anything else I can try?

12:31:10:922   7a7a2780   GPU 6 temp = 63, old fan speed = 80%, new fan speed = 80%
12:31:10:930   7a7a2780   GPU0 t=69C fan=60%, GPU1 t=63C fan=80%
12:31:10:930   7a7a2780   em hbt: 1, fm hbt: 24,
12:31:10:930   7a7a2780   watchdog - thread 0, hb time 270
12:31:10:930   7a7a2780   watchdog - thread 1, hb time 402
12:31:10:930   7a7a2780   watchdog - thread 2, hb time 133
12:31:10:930   7a7a2780   watchdog - thread 3, hb time 5
12:31:10:930   7a7a2780   watchdog - thread 4, hb time 63268
12:31:10:930   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 5, hb time 62960
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 6, hb time 63134
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   watchdog - thread 7, hb time 63397
12:31:10:931   7a7a2780   WATCHDOG: GPU 1 hangs in OpenCL call, exit
12:31:10:931   7a7a2780   OC v5, Reset control for GPU 0, close miner right now if you want to use default control from Catalyst
12:31:10:932   7a7a2780   OC v5, Reset control for GPU 6, close miner right now if you want to use default control from Catalyst
legendary
Activity: 1084
Merit: 1003
≡v≡
I always wanted to ask has anyone tried to mine on win server? Any of them 2008, 2012?
While the system is designed to run 24/7 I think there might be less chance for system failure after blackouts and less chance to freeze.
Anyone?
hero member
Activity: 711
Merit: 500
I see some of you guys getting 300+ H/s from RX 480's.
What is being done doing to achieve that?

Modded memory timing.

That is not necessary. My downclock SAPPHIRE NITRO RX480 8 Gb OC+ ( stock BIOS) hashed  300 H/s (1200 MHz GPU, 2100 MHz GDDR5). Hashed be even more on the default clock (1342 MHz GPU).
newbie
Activity: 15
Merit: 0
I see some of you guys getting 300+ H/s from RX 480's.
What is being done doing to achieve that?

Modded memory timing.
full member
Activity: 148
Merit: 102
I see some of you guys getting 300+ H/s from RX 480's.
What is being done doing to achieve that?
sr. member
Activity: 1484
Merit: 253
Using R9 280X with modded bios and some overclocked GPU. v12 works fine. Tested over 2-3 days working without issuies.

With v12.1 only 1st intensity is most stable. With any other intensity miner after about 10 min starts to show 0 hashrates and 0% GPU load.
With 1st intensity miner works normal 20-30 min and then speed is 0 too. Miner restarts and so on.

Returning back to v12. It's stable for me.

Windows 10 Pro.
Tryed 15.12 drivers, disable overclocking. Nothing helps.
Any other miners works fine. PSU 60-70% load.
legendary
Activity: 1176
Merit: 1015

For those of you who were around when Ethereum went from Alpha to beta, we are now in the same place with Sapling in Zcash. I'm not saying it's 'going to happen' but Ethereum wen't from $0.50 - $34 in the 6 months following their second release.. AND we also have Ethereum moving to POW which most likely will push miners over to Zec, raising diff and price.

Food for thought, and let's keep our fingers crossed Smiley

No need to keep your fingers crossed, still waiting for kraken/ poloniex to enable margin trading on zec. When that happens it takes less than 24 hours to see what real value right now is.

Comparing to eth, margin trading started in Aug 2015, wonder why it takes so long for zec )


Agreed,
I do believe however that Margin trading most likely will follow the Sprout release as it signals some network maturity and will require upgrade of wallets and infrastructure software. But I agree, margin trading is the starter gun for a drastic valuation uptick.

Before it can go up it first needs to be shorted to oblivion.
donator
Activity: 1610
Merit: 1325
Miners developer
Miner does not use 1.88 factor in calculations, using it is a bad idea because it is theoretical factor and real implementation may be not so good. Therefore miner just counts all solutions found, and time that was spent. If algorithm implementation has a bug that causes 1.8 factor, it will cause less number of solutions and less calculated hashrate. So this idea is wrong.
I still think it's related to pool. What pool do you use? I will put all my polaris cards to it and check 2-3 daily hashrates to see hashrate deviations.

Claymore I found your bug...seems like shares are dropped when there is high network latency in your share queue (time after block is found on network, network disconnects, pool disconnects etc). Either there is a bug in your share queue that not properly submitting queued shares, or when you do regain connection to pool, you dump all the shares at once to pool and pool software might be blocking/loosing those submits.

Below you can see a test of my theory, network is manually dropped at 12:58:22 and reconnected at 12:58.36 and in that time system finds 18 shares, but only 15 reach the pool.

This issue is obviously magnified by larger rigs since the faster the system finds shares the more shares will eventually be dropped if there is a network latency, so it explains why you or others might not see the same behavior. Maybe put in a slight delay(10-20ms) between queued shares so they are not all dumped at the pool at same time?

PM me entire log file, I'll check it.
legendary
Activity: 2174
Merit: 1401
Miner does not use 1.88 factor in calculations, using it is a bad idea because it is theoretical factor and real implementation may be not so good. Therefore miner just counts all solutions found, and time that was spent. If algorithm implementation has a bug that causes 1.8 factor, it will cause less number of solutions and less calculated hashrate. So this idea is wrong.
I still think it's related to pool. What pool do you use? I will put all my polaris cards to it and check 2-3 daily hashrates to see hashrate deviations.

Claymore I found your bug...seems like shares are dropped when there is high network latency in your share queue (time after block is found on network, network disconnects, pool disconnects etc). Either there is a bug in your share queue that not properly submitting queued shares, or when you do regain connection to pool, you dump all the shares at once to pool and pool software might be blocking/loosing those submits.

Below you can see a test of my theory, network is manually dropped at 12:58:22 and reconnected at 12:58.36 and in that time system finds 18 shares, but only 15 reach the pool.

This issue is obviously magnified by larger rigs since the faster the system finds shares the more shares will eventually be dropped if there is a network latency, so it explains why you or others might not see the same behavior. Maybe put in a slight delay(10-20ms) between queued shares so they are not all dumped at the pool at same time?

full member
Activity: 176
Merit: 100
Hello,

Thanks for the new release  Smiley

With my R9 290x i'm reaching 330 H/s at stock speeds (even with playing with -i).

To anyone that have an R9 290(x) : can you confirm my results please ?

Thanks


290x @  940mhz / 1250  = 364h/s

modded bios
V12
R15.12
Jump to: