Claymore's ZCash/BTG AMD GPU Miner v12.6 (Windows/Linux)

[IOTUSA]

zec will start rally soon, dont worry child

You've got it right! Over 20% pump is going on. Hopefully won't follow a dump  

There will be no dump, we will get price at 55/60usd by the end of next weekend

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

[GamerMiner]

Hello,

Thanks for the new release 

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

[Corerj]

Hello,

Thanks for the new release 

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

same here... but i saw people talking about 400sols with modded rom...tried to tweak my 295 but no success...

[antantti]

zec will start rally soon, dont worry child

You've got it right! Over 20% pump is going on. Hopefully won't follow a dump  

There will be no dump, we will get price at 55/60usd by the end of next weekend

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

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 )

[IOTUSA]

zec will start rally soon, dont worry child

You've got it right! Over 20% pump is going on. Hopefully won't follow a dump  

There will be no dump, we will get price at 55/60usd by the end of next weekend

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

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.

[spyshagg]

Hello,

Thanks for the new release  

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

[jstefanop]

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?

[Claymore]

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.

[antantti]

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

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.

[UnclWish]

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.

[Socket54]

I see some of you guys getting 300+ H/s from RX 480's.
What is being done doing to achieve that?

[Bidnant]

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.

[Lucky - Luciano]

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).

[mettalmag]

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?

[silentrunner]

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

[mettalmag]

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

[UnclWish]

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.

[Corerj]

-i 1 seems to solve the hang issue for me...

[silentrunner]

-i 1 seems to solve the hang issue for me...

It was already set to -i 1

[UnclWish]

-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...