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

R9 290 4GB 230 H/s
All stock

Please share your speeds of  
R9 280X (R7970) 3GB 384 BIT GDDR5
AMD Sapphire R9 280X VaporX Edition
XFX Double Dissipation R9 290 4GB 512 Bits OC

Thanks

How do u enable remote management? -mport 3333 dont seem to work?

Please share your speeds of  
R9 280X (R7970) 3GB 384 BIT GDDR5
AMD Sapphire R9 280X VaporX Edition
XFX Double Dissipation R9 290 4GB 512 Bits OC

Thanks

Hello
I have an issue around claymore zcash miner.After 10-60 min of the starting mine I get following error .I have tried win7-8.1 with various AMD drivers such as 15.12 and 16 series even several risers but this error still remains.Core clock and voltage are default values moreover I have created reboot.bat file but after auto restarting of miner, GPU 0 won't work and it gives me 0 hash but GPU 1 still works properly.
I have 2 ASUS r9390x dc2 on each mainboard and all of mainboards have this error.
Please fix this bug in next version or give me a solution.

error:
WATCHDOG: GPU 0 hangs in OpenCL call, exit
08:32:42:037 1adc watchdog - thread 1, hb time 76254
08:32:42:037 1adc WATCHDOG: GPU 0 hangs in OpenCL call, exit
08:32:43:100 1adc Restarting OK, exit..."

This is not question of memory througput.
Reducing memclock almost twice affects only to 20% hashrate drop.
https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.piccy.info%2Fi9%2Fce2e18589c91c75caab3b10a46a2c9f2%2F1480097808%2F34039%2F1051816%2Fmemdrop.png&t=571&c=zWfZWhuCJrGaPQ

While my initial analysis was focused on the external GDDR5 bandwidth limits, current ZEC GPU mining software seems to be limited by the memory controller/core bus.  On AMD GCN, each memory controller can xfer 64 bytes (1 cache line) per clock.  In SA5, the ht_store function, in addition to adding to row counters, does 4 separate memory writes for most rounds (3 writes for the last couple rounds).  All of these writes are either 4 or 8 bytes, so much less than 64 bytes per clock are being transferred to the L2 cache.  A single thread (1 SIMD element) can transfer at most 16 bytes (dwordX4) in a single instruction.  This means a modified ht_store thread could update a row slot in 2 clocks.  If the update operation is split between 2 (or 4 or more) threads, one slot can be updated in one clock, since 2 threads can simultaneously write to different parts of the same 64-byte block.  This would mean each row update operation could be done in 2 GPU core clock cycles; one for the counter update, and one for updating the row slot.

Even with those changes, my calculations indicate that a ZEC miner would be limited by the core clock, according to a ratio of approximately 5:6.  In other words, when a Rx 470 has a memory clock of 1750Mhz, the core would need to be clocked at 1750 * 5/6 = 1458Mhz in order to achieve maximum performance.

If the row counters can be kept in LDS or GDS, the core:memory ratio required would be 1:2, thereby allowing full use of the external memory bandwidth.  There is 64KB of LDS per CU, and the AMD GCN architecture docs indicate the LDS can be globally addressed; i.e. one CU can access the LDS of another CU.  However the syntax of OpenCL does not permit the local memory of one work-group to be accessed by a different work-group.  There is only 64KB of GDS shared by all CUs, and even if the row counters could be stored in such a small amount of memory, OpenCL does not have any concept of GDS.

This likely means writing a top performance ZEC miner for AMD is the domain of someone who codes in GCN assembler.  Canis lupus?

Zecminer64.exe = virus?

Kaspersky said...

Any ideas?