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

Maybe WDDM 2.7 technology would help to resolve the degradation?
It's supported in NVIDIA beta drivers 450.99 and will be included in final 451.13

https://www.reddit.com/r/intel/comments/f9ztf8/wddm_27_provides_better_performance_for_intel/

PhoenixMiner 5.0c is officially released. You can find the download link and the checksums in the first post of this thread. This is a minor update over 5.9b with support for the latest AMD Windows driver.

The new features in this release are:

• Added support for latest AMD Windows driver 20.5.1
• Added SO_REUSEPORT option on the remote control port (default 3333) under Linux to prevent problems when the miner is restarting

If you are already running PhoenixMiner 5.0b, there is no need to update to 5.0c unless you want to run AMD Windows drivers 20.5.1, or need the small improvement for the Linux version.

    We have tested with the same Linux drivers 19.20-812932 on Ubuntu 18.04 LTS (slightly older kernel but still 5.x) and everything works fine. Please check your other settings (i.e. clocks), and make sure that you are using auto-tune to find the best -gt values (they could be very different than before DAG epoch 350). Also, sometimes just restart of the rig solves such strange problems.


    The blockchain driver is not tested with the new big DAG kernels and probably is not working properly. Install newer drivers (anything from 18.12.1.1 to 19.7.5) and make sure that you have switched the GPU Workload to Compute mode (by default they are in Graphics) in the AMD Control Center.



    We will definitely continue to support AMD 8 GB cards in the future. However this approach probably won't solve the Nvidia slow degradation of hashrate with each new DAG epoch.


    There are no changes in -clkernel 3 - it is working as it was before. The problem is in the AMD drivers, which start to partially allocate shared memory (i.e. the mainboard RAM) as part of the DAG buffer as the used VRAM approaches 7.4-7.5 GB, which leads to sharp decrease in the hashrate. So, unless they fix it in the future drivers, -clkernel 3 is not viable for epoch 350 and above.


    Please check if your cards are switched to Compute mode in AMD control center. It is easy to miss if you are coming from the blockchain drivers, where there wasn't such option.




    The problem is that your video card is probably used by Windows and there are only 3.33 GB free VRAM, while the Ethereum DAG buffer requires 3.66 GB VRAM as you can see the the log file. So, you have either mine another coin with lower DAG epoch, or mine on another video card, with more free VRAM.

Hi all,
Fairly new here to mining (as of 2 hours ago),

Can anyone help me with this please ?


Eth: Giving up after 3 retries, switching to next pool
Eth: Reconnecting in 5 seconds...
Eth: Connecting to ethash pool us2.ethermine.org:14444 (proto: EthProxy)
Eth: Connected to ethash pool us2.ethermine.org:14444 (172.65.226.101)
Eth: New job #c02829d6 from us2.ethermine.org:14444; diff: 4000MH
GPU1: Starting up... (0)
GPU1: Generating ethash light cache for epoch #339
Eth: New job #89396b4b from us2.ethermine.org:14444; diff: 4000MH
Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:01
Light cache generated in 3.8 s (15.6 MB/s)
GPU1: Allocating DAG (3.66) GB; good for epoch up to #341
CUDA error in CudaProgram.cu:373 : out of memory (2)
GPU1: CUDA memory: 4.00 GB total, 3.33 GB free
GPU1 initMiner error: out of memory
Fatal error detected. Restarting.


Error 2 while trying to restart


I have a Nvidia GeForce GTX960 4gb ddr4 on a AMD FX8320 rig with 32gb ddr3 running win10

Tested on my computer (32GB RAM) with 8GB RX570, driver 19.9.1 and epoch 353. clkernel 3 works but the hashrate falls from 28.4MH/S (with clkernel 1) to 21 MH/S (with clkernel 3). I suppose you don't have enough physical or virtual memory but even if you had it you won't like the -7 MH/s fall. The problem is in the driver. It takes about 300MB shared memory from your computer and the transfer with this memory leads to this -7MH/s fall (if your GPU is not on PCI-E X 16 like me this fall will be at least -28 MH/S). So you can't use clkernel 3 because of the driver. There is enough VRAM for 2 X DAGs (2 X 3.77 GB for epoch 353) used from clkernel 3 but the driver decides to use your computer memory. There is no way to tell it not to do it. If you check all the drivers from 18.1.1 to 20.5.1 maybe (maybe not) you will find a driver that doesn't allocates host (computer) memory, but the chances are very small.

clernel 3 uses double the memory of clkernel 1. So when x > 4 => 2.x >8
Installing PM 4.9 and/or driver 20.5.1 may fix your problem for some time.

Yes i am using Win10x64 LTSC version with "latest" 20.4.2 driver.
And yes i know that Win is using my vram if there is a display connected to it.
I am mining with my PC 1x580 8GB without iGPU and i have one rig#1 with 4x480 8GB with iGPU and a mixed rig#2 with 1x580 8GB 5x470 4GB with a iGPU
Yesterday the #1 4x480 8GB gave me problems with clkernel3 and the fix was switching to clkernel1.
Everything was fine until ETC epoch 347-348.
Simple logic if 4gb cards work clkernel1 then 8gb cards should work clkernel3 or am i wrong?

You using Win10? Which driver you are using. You can't just calculate 2x3.75.
Can you mine ETH with clkernel3? If so, then you have not enough vram for ETC and clkernel3. What driver your using.

where you find the version 5.0c?

What Bios you are using for the RX580? Which driver version? Which OS? OC your Cards? How you oc your cards?   

With 0 information, helping is very hard 

I tried both versions of the miner 5b-5c and at least 5 types of drivers and the maximum speed I achieved is 10.4m per card. The cards are RX 580 4G. I will be happy if someone shares if this problem can be fixed.

If my mem is 8 and 2x3,75=7,5 (current ETC) there is still 0,5 free mem
I guess if 4gb cards are working on -clkernel 1 then 8gb should work on -clkernel 3
Or i am missing something...

-clkernel 3 uses 2 DAGs so 8GB are not enough to hold them and it will stop working at some moment when DAG size approaches 4GB.

+1 same question

Anyone kind enough to help me out with some good settings for 8 Sapphire RX570 16GB cards for mining ETH on Linux Ubuntu 18.04.4 (currently using 18.50 AMDgpu drivers)?  

I've had a few issues (Everything is stock, both the cards and miner.):

1. After about a full day or 2 of mining it would give me an error about Vram. Which makes little sense to me as the card has 16gb.

2. Threads are getting stuck, stopping the miner to where I must do a system shut down and restart.

3. Lots of Incorrect shares.

I appreciate any input and/or guidance to get this setup to achieve stability, thank you.

I did some testing and it appears that there is a problem with -clkernel 3 on 8GB cards, the turbo kernel does not work anymore, changing back to -clkernel 1 did the job but it gives a little less hashpower.
PhoenixMiner or someone, could you please verify and confirm the same problem.
PhoenixMiner tnx and keep up the good work.

Dear Phoenix,

Do you have any plans to add the DAG-split feature to your miner?

For AMD - to allow 8-gig cards to continue mining ETH after the DAG exceeds 4GB
For NVIDIA - to fix the ETH speed reduction because of the raising DAG (on 10xx cards)

That's your problem. The solution for using 4GB AMD cards doesn't work on drivers before 2018. Install at least 18.1.1

NO I DIDNT SEE THAT
AND IAM USUING THE BLOCK CHAIN DRIVER FROM 2017 "22.19.659.0"

OpenCL 19.20 AMD Driver
OS: HiveOS 0.6-142@200528
linux Ядpo 5.0.21-hiveos
4Gb AMD Asus Cards STRIX
Phoenix 5.0b

after epoch 350 in Nicehash Ethash I have low hashrates ~ 10-15 mhs from card.  after creation ETC DAG
-dagrestart 1, dont solve the problem. ((
What I am doing wrong?  Thx a lot

Do you see "Unknown OpenCL driver version! Hashrate and stale shares may suffer" in the beginning of your log? If that's the case you have to reinstall your driver with version higher than  18.1.1 for Windows. Use also DDU to fully uninstall your previous driver. If your driver is 20.5.1 upgrade to PM 5.0c which supports this driver.