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

Interesting, I lost you at the end, keep thinking how is it known that "gpu cant handle", because if you see bad shares you can actually understand it's not working, so your rate is shit. but now if its about Navi then I don't have any ... yet (is it the 7nm one? like in two flavors 5700 and 5700xl or something?)

well it's not the case for me I had some weirdness on 12 polarises, that were misbehaving as it is... so maybe or maybe because you don't use this tool: https://bitcointalksearch.org/topic/amd-mem-tweak-xl-readmodify-timingsppstraps-on-the-fly-5123724
dunno. do you use it? it's being actively integrated into miners:)

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.

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

this is my page now   and whomever sent me that email with sig campaign on yobit, that made me finally connect yobit to the awesome service I use:
https://bitsgap.com/?ref=223387b - you can get 10% off your first purchase from my affil link. And I did paid them (advanced for a year for now) and so far very happy and finally keep my stops off the exchanges and place almost proper stop-loss+take profit orders bots returned the yearly fee almost within a free period for me.

They have very nice unified trading platform and here I test 5 of my bots: https://bitsgap.com/bot-sharing?id=BF322202 are running from the last week, as you can see

It's cause what i wrote - miner didn't support new OpenCL driver from 19.9.3 drivers. When miner haven't full support of driver it works only with generic kernels, give speed jumps up and down and gives many rejected shares.

what is this "fake hashrate" are you talking about? and what is wave32 is it suppose to be an opencl function? I'm confused now was I paid by the pool that was fooled by my fake hashrate as well? or did they just made me feel I was underpaid constantly?

Well that opencl thing that was going around here, fake higher hashrate, it is not working anymore. and it was linked to wave32 i suppose, now even if u change it on new drivers, it does nothing.

just curious, are you sure of that? so they started immediately fucking with people, releasing more backward incompatible (maybe driver API changes) shit... nice...
and people prove the point downloading new shit because they hope for the best:)))

2. good start is 836 and make it stable
4. dont use GPUZ for volts monitoring, use HWinfo64 instead properly configured for sensors only and "not invasive" scan of busses, nor AFB (even if I have Afterburner installed I disable it from autostart normally- its VERY bad shit, even though sometimes can solve issues)

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)

Not only that, but there was also changes how opencl work with kernels that we have right now, better stay on 19.9.2 at this moment.

Checked by myself... Driver 19.9.3 is not supported! Miner needs update to support new drivers.

here some pictures to the story of a hang in a driver:)
now tried to open hwinfo (and yeah it initiated the GPU query and I started to move the miner window inside just to fuck with it, otherwise its stable for days) to see the numbers and got this:


and here its recovered on itself after watchdog reset



note the volts  - still can be lower, may depend on card and condition, for instance sapphire 56 pulse with hands on I have here is running at 819mv I think and doing 43.5MH (as the head gpu with display dummy for bigger RealVNC display size - RDP works with any, but very heavy on resources and slow as hell on itself) on ETH

@Guigs321
I can tell you a funny story about buggy driver setup I have in my remote location.
Well, I currently have one very weird vegas setup: around driver 18.5.1 I had succeeded to connect two types of vegas on a same machine (1060 & polaris worked fine with both rx and fe separately even then, but vegas fe is a fucking nightmare, especially in its driver part or maybe it's just the remote conditions to blame, whatever. I remember that to set it up I needed to physically remove the cards, leave only vega fe: then there appears an an option to switch pro drivers to game mode and then I could install 18.5.1(I think) SAME adrenaline version for vegas rx. and it worked.
so anyway I finally got my hands on improving the vegas state - they were doing very low xmr on (my rebuild without the fee) stak-xmr, like 30% lower than I could get on later drivers without the FE presence:)
so, I was fixing the PowerPlay tables and by mistake applied not the FE PPT (that I had separately), but vega64's.
(to reduce ourageous voltage and as my vega fe was the dev0 - remember earlier? - cant move the cards around) I was getting GUI part of windows non working completely, so my vnc or rdp wont go through smooth - I saw very strange memory ranges sometimes:)...hell nothing worked or responded from gui
but I have hw reset watchdog, that I can access via cmd line...so... good thing I had admin access enabled, so using pstools I fucking nuked the registry key despite periodic disconnects and restarts -due to my awesome watchdog timeouts, while the AMD driver never fucking returns. (btw only logged in as the System account could modify the registry)

..it's now fine on latest rtm after applyng proper ppt and amdmemtweak. 56 refs are doing best over 2100 on xmr. all above 2000 and cool, taking 822W from 2*750 ... or is it three.. lol evga psus.

NOTE: I had there initially (its asus btc 13 slots mobo) 2*fe+2*vega64 ref+2*vega56ref so figuring out to take one fe out as a necessary step didn't appeal to me fast enough:) now I took one FE and one 64 refs out.

Asus RX580 8G Stock bios - 33.5Mh/s 1240Mhz core@875mV 2250Mhz memory - 93W 

Yes I think, but will not debate of that with you.

1. Yes it depends
2. It's a good start
3. I get's 31,140 Mhz per card on my RX470 4GB rig and 34 Mhz per card on my RX580 8 GB rig just under 900mV (I cant' go under 900mV and I don't know why...)
4. The power consumption I was talking about it's the  "GPU Power draw only" item from GPU-Z

If you have a tips for me to have 875mV please share with me. I tried MSI AB, Sapphire Trixx, OverDrive, AMD Tweak Memory... It's shows 875mV but never applied in GPU-Z

here's an example for you. please note that for the sake of stability the cards are not maxed out. also there could be some issues with raisers - hence some low performing cards. it's in remote location and hashing non stop for two years now. rx570, 11 sapphires with elpida and 1 hynix all 4GB.
all modded bioses, 18.6.1 driver, OVDT for voltages, amd mem tweak for improved timings.



Combine two numbers and you'll get the power consumption around 130W, which is about right in this case. it takes total from the wall about 140W per gpu including fans, system and everything.

Mine 1170~1180 core on 875mV, that should be doable

hmm... Do you think you are actually qualified to give an advice on the subject?
1) driver does not "hang" in a way that "hasrate is reduced", it may get to 0 but its usually not the driver
2) 900 mv is not a good voltage
3) with all the tools available today for ploaris you should expect over 30mh and up to 33 (again at lower then 900mv)
4) I hope you understand that the power consumption numbers you are discussing here is total crap. His card on stock voltage and 1400 core consumes around 200W