Topic: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux) - page 314. (Read 784965 times)

Currently using AMD Vega 64, however, cant manage to get above 34.9MH, not even earning profit, any advice?

Because of the GTX1050Ti (and other 4 GB Nvidia cards) problems under Windows, here is a special release that will solve the issue for a few more weeks. That's the best that can be done, because Nvidia drivers just won't allow to allocate enough VRAM even when it is available. Note that if you don't have 4 GB Nvidia cards, there is no point to use the 4.7a - there are only some small fixes for rare bugs. You can download PhoenixMiner 4.7a from here:

https://mega.nz/#F!fVUGRK4C!CRF040jyvAgr-DJDBn-gTQ  (MEGA)

If you want to check the integrity of the downloaded file, please use the following hashes (you need the last file PhoenixMiner_NVRTC_Windows.zip only if you want to mine BCI with Nvdia cards under Windows):

Here are the new features for this release:

• Reduced VRAM usage for Nvidia cards on Windows to allow slightly longer operation of 4 GB cards under Windows 10 (few weeks to a month, then the problem will appear again)
• Other small improvements and fixes.

Remember to add -rvram -1 -eres 0 to your command-line or config.txt file in order to lower the memory usage as much as possible.

Yes, of cause I'm using AMD MemTweak Tool, but not XL variant. Old one, that works with secure boot. I'm use it only for setting REF.

My Polaris cards works fine with 19.9.2 with full speed as on any other driver.

@cikusa


and here i have an issue with semi-permanent exclusively bad shares production on some of my polarises with Hynix:  
https://bitcointalksearch.org/topic/m.52574444

EDIT: surely no offence, why, I agree with you:)

Yes i am talking about 5700 and 5700xt, incorrect share does not mean that gpu is not working, it means it is giving shares that are not valid. U can compare it in fact with incorrect share that happen if memory if overclocked too much and it is giving too many errors.

I told you 19.9.2 is the one to try - it gives slightly lower hashrate on polaris with my configs, but works well.
I think 19.9.2 is the improved one over the previous where they fixed 5700 dag(which is a must for support) bug... if I'm not mistaken or is it 7500... lol)

Yes i am talking about 5700 and 5700xt, incorrect share does not mean that gpu is not working, it means it is giving shares that are not valid. U can compare it in fact with incorrect share that happen if memory if overclocked too much and it is giving too many errors.

Well let's say this
"
There are architectural changes which affect how code is scheduled:

Single cycle instruction issue:
GCN issued one instruction per wave once every 4 cycles.
RDNA issues instructions every cycle.
Wave32:
GCN used a wavefront size of 64 threads (work items).
RDNA supports both wavefront sizes of 32 and 64 threads.
Workgroup Processors:
GCN grouped the shader hardware into "compute units" (CUs) which contained scalar ALUs and vector ALUs, LDS and memory access. One CU contains 4 SIMD16s which share one path to memory.
RDNA introduced the "workgroup processor" ("WGP"). The WGP replaces the compute unit as the basic unit of shader computation hardware/computing. One WGP encompasses 2 CUs. This allows significantly more compute power and memory bandwidth to be directed at a single workgroup. In RDNA 1 CU is one half of a WGP.
"

So as u can see most of old GCN gpu works in wavefronts of 64 threads in 4 cycles, and new RDNA is doing instruction every cycle. So what i my guess is that that on driver 19.9.2 u could force driver to give 5700xt  64 threads to deal with and then cards were showing hashrates up to 58mh even more but it was also giving incorrect shares so effective hashrate was acaually lower than it was showing on miner console. Now once again my guess is that via wavefront of 64 on Navi u were just giving too much instructions to gpu that gpu just could not handle, since on GCN they were done in 4 cycles and here they need to be done in one cycle. So i suppose later on there will be some new kernels optimized for Navi architecture that will be able to get that hashrate without any incorrect share. Take this with grain of salt, i am far from expert on this field, this is just my understand of it.