Quote from: Biterion on November 28, 2020, 09:53:02 PM

after 6 more hours make update to win10.. (i can't sleep.. here 4:54AM now) Grin

used AMD Driver 12.4.2 >>> i can see my GPU all work in device manager Grin

patch by 'atikmdag-patcher-1.4.7'
switch to compute mode by 'AMD-Compute-Switcher'

but,...
using Phoenix miner 5.2e and 5.3b still same, hashrate still not change like before..

here is the result:

....

any suggestion to make RX480 back to 30Mhs..?
thanks

Remove the -straps command - it is not supported on Polaris GPUs. Then try mining ETC to see the normal hashrate (you need PhoenixMiner 5.3b) when the DAG actually fits in the VRAM.

You won't be able to mine ETH with full speed on 4 GB cards under Windows any more but it will be more like 20-23 MH/s with the current DAG epoch and will go down a little with each new epoch - you will need to let auto-tine to finish in order to see the final hashrate.

Quote from: waywoos on November 28, 2020, 10:55:26 PM

trying to run 2 phoenixminers at same time.
one for etc 4gb and the rest are 8gb with eth.
i have them both admin rights but get an error.
unable to start cdm server at port 3333. only one usage of each socket
any ideas?

i looked into the readme
what will -cdm 0 do for me?
is it safe?
it seems to be working that way
thanks for help

Even with the error they will work side by side but one of them won't be accessible via the remote port (the one that is started second). To avoid this, change the remote control port in one of the instances to something else than the default 3333, for example -cdmport 3334
It is also a good idea to run the instances from different folders to avoid mixing up the log files, .bat files, config files, etc.

Quote from: radoisloco on November 28, 2020, 11:20:57 PM

Hi there. I'm trying to mine with a rig of 1060 3GB, and I get DAG BUFFER error.

Code:

2020.11.28:15:15:46.574: GPU4 GPU4: Allocating DAG (2.54) GB; good for epoch up to #197
2020.11.28:15:15:46.574: GPU4 CUDA error in CudaProgram.cu:388 : out of memory (2)
2020.11.28:15:15:46.575: GPU4 GPU4: CUDA memory: 3.00 GB total, 2.43 GB free
2020.11.28:15:15:46.575: GPU4 GPU4 initMiner error: out of memory
2020.11.28:15:15:46.575: wdog Fatal error detected. Restarting.

I am using pm 5.3b in windows and I am setting memory allocation in windows settings.
And I am also using the start_etc BAT. Still can't get it to work.

does anybody else have this problem?

The problem is here: GPU4 GPU4: CUDA memory: 3.00 GB total, 2.43 GB free - Windows "eats" the VRAM of your GPU and only 2.43 GB are free. You need at least 2.5 GB for the ETC DAG buffer.

Quote from: noobminer88 on Today at 02:18:03 AM

Hi.
Will you add preloaded DAG 0 for ZIL mining. Thank you.

We will see what we can do in the next release.

Quote from: Johndrc on Today at 02:59:51 AM

Quote from: noobminer88 on Today at 02:37:02 AM

Quote from: Johndrc on Today at 02:23:21 AM

5.3 why it autoswitch from ethermine to miningpoolhub wtf

maybe dev fee ?

Its not returning back to ethermine, its not dev fee, its robbery!

No, miningpoolhub is not used for devfee on ETC, nor it is possible to switch to it "automatically". You either have downloaded fake copy of PhoenixMiner from somewhere (the only official sources are our posts in this thread, including the checksums to verify the download), or you are just making things up.

Quote from: hashjunkie on Today at 07:39:15 AM

Win10 user here with a single RTX 2060 Super, and 24GB of virtual memory page file already configured on my gaming PC.

Recently upgraded to Phoenix Miner 5.2e for testing on Nicehash & ETH on Ethermine, but I am still getting the same problem as before when I was on 5.1c - Phoenix would simply crash at random with no warning or errors after several hours of mining. I have looked at the logs and the common theme I've been seeing is that it crashes during the DAG file creation process. Below is a sample of the final moments as captured by the Phoenix log just before the miner crashes.

Quote

2020.11.29:17:55:13.444: GPU1 GPU1: Starting up... (0)
2020.11.29:17:55:13.444: GPU1 GPU1: Generating ethash light cache for epoch #0
2020.11.29:17:55:14.044: GPU1 Light cache generated in 0.6 s (26.7 MB/s)
2020.11.29:17:55:15.614: GPU1 GPU1: Allocating DAG for epoch #0 (1.00) GB
2020.11.29:17:55:15.642: GPU1 GPU1: Generating DAG for epoch #0
2020.11.29:17:55:15.749: main Eth speed: 0.000 MH/s, shares: 45/0/0, time: 0:32
2020.11.29:17:55:16.418: eths Eth: Received: {"id":null,"method":"mining.notify","params":["0000000047936db6","0000000000000000000000000000000000000000000000000000000000000000","fe24abd0fd26cde9dda8a15fc6cb485f248494a864bf37cce71afef0e36744d9",true]}

This problem also occurs at random epochs, regardless of the pool, or any -eres or -lidag values I use in the config file. I tried to mitigate this with the -rmode parameter (wdog is enabled by default) but it does not work. The problem also manifests itself with or without the NiceHash Miner client running....

The OC is what I would consider relatively mild - 1650mhz cclock (+100) / 765mV vCore (53% power limit) / 7650mhz mclock (+650), and has been working very stable for me in the past. I have also specified -nvdo 1 on the config settings and also rolled back my NVidia drivers back to v432.00, and I also confirm that the Phoenix Miner EXE file is on my AntiVirus exception list.

I am at a complete loss and appear have hit a brick wall (yet again) - any suggestions or ideas on what else would be causing this problem?

The only suggestion that comes to mind is to check temperatures, and to remove the core and memory overclock for a while to see if this makes a difference.