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

What is your startup script?

Also try adding

-lidag 3 to it. See if that helps.

What doea your startup script look like?

-li, -mi and -ethi does not work on PhoenixMiner, any idea why?

What driver version or versions was this coded for? What are the driver settings the optimizations affect if you dont mind dropping some knowledge? What ever they are they seem to work for stability.

I ran a VII and a 590 together on my pc, so sure...

Will it allow RadeonVII and 570 on same rig?

Hi guys,
recentl I use this great miner, but last 3 days I get very annoing problem:

Eth: Unable to read pool response: An existing connection was forcibly closed by the remote host
Eth: Reconnecting in 20 seconds...

I try almost everything but stil comes up may be this is a issue with my ISP, I don't know.
Please reply if someone have same troubles and know what is solution.
Thanks in advance.

I had a sort of similar issue and i found 1 card had tilted slightly in its riser. I went and resat all cards and things went back to normal.

warming up is not a case, last time started happening at 5 am, when cards are usually coldest. even during the day, cards run at 45c with fan 21%, 21% is minimum fans can spin
Also tried changing clocks, didnt helped. Running for 6 months on phoenix with same clocks and no problems before this

Weather warming up, maybe to much power draw because of more heat to dissipate. If you OC + undervolt, maybe you should lower the clocks or raise a little bit the voltage.

So came across strange thing. i have only one rx480 in rig with few rx580s, everything was working ok up until maybe month ago.
rx480 started giving incorrect shares, a lot of them, before it would give few in a week. Now all of sudden, card would in give in 5 days 7 incorrect shares (normal more or less) and then would just start giving enormous amount of incorrect ones (every 3rd or 4th would be CORRECT one)

I tried to check logs, but nothing unusual in them.
Restarting rig helps, for 4-5 days then everything starts all over again.
Radeon software version 19.1.1
phoenix 4.1c

Did anybody have similar problem or know solution for it?

Thanks

Hi all ... anyone using the -pauseat command? It doesn't seem to work with time(24h). Whatever the time is set it always pauses mining from the start.

Phoenix, please add AMD 19.4.1 driver support.

yes, there was v3 kernel in log file after creating DAG. P104 is more likely 1070 with fast memory.
I found that decreasing power limit reduces hasrate on 0,038MH/1W. but I do not tested yet if it works only with v3 kernels.

   Yes, the bench mode doesn't support BCI (or dual mining for that matter) yet. This will be implemented in the next release.


   In the same way as Claymore's miner: add the desired command-line parameters in config.txt file, optionally add the pools in epools.txt if you want to be able to change them without restarting the miner, then just run PhoenixMiner.exe by double-clicking it. Note that there are example config.txt and epools.txt files in the PhoenixMiner's folder - you just need to change the wallet address in config.txt file to your own wallet address.


   Will be implemented in the next version.


   If you have integrated GPU, it is best to use it for the OS, display, etc. However, even with using one of the mining GPUs as primary adapter, the OS shouldn't "eat up" so much VRAM from your GPU unless you are running some software using 3D acceleration or compute.


   Can you confirm that you are seeing v3 kernels loading in the log file? (it should be in the first few pages of the log file, immediately before the card starts to actually mine). We have tested on GTX1080, which should be the same as P104 but perhaps the better memory timings in P104 cause the difference in behavior.


    Please let us know which OS, and drivers you are using. There are no big changes in AMD kernels, but we have added the -fcm option to force better fan control if the drivers/VBIOS doesn't cooperate when "asked nicely" The default value is -fcm 0, which basically asks the VBIOS/driver to keep the card at specified temperature, fan speed, etc. However, if the driver ignores the request (as it started doing in some of the latest 19.x drivers), PhoenixMiner switches to the "forced" method. Most probably your cards are hitting the thermal limits or power limits (or max fan speed limits, etc). You can get the old behavior by specifying -fcm 1, which will force PhoenixMiner to use only the old fan control method even if the card doesn't behave as instructed.


    You have accidentally pressed one or more keys (most probably 'e'), which should be followed by digit key(s), specifying which pool in epools.txt you want to use. The miner just complains that the next pressed key is not what it expects.



   This seems like a "normal" pool connectivity problem - for whatever reason the connection to the pool is not stable. If this happens again and again with the same pool and with PhoenixMiner 4.2 but not with 4.1, let us know and we will look into the issue. In such case, please send us a log when this happens (on PM if you want), and we need at least five minutes or so before the connectivity problems, or just send the entire log and we will analyze it.


    Very nice, some of us may start to stockpile Radeon VII for the next mining boom Hopefully there will be custom cooling versions too.


    For 24/7 operation we run our R7s severely underclocked and undervolted at 1200 MHz/7xx mV (depending on the card), because they are too loud, and they still make 62 MH/s per GPU!

that's great!
thank you

It's not even close to efficient if that's the question...  Even @ 90MH/s you're burning too much power.  80-85 is a good spot, I'm doing 82 @ 215w.

what about power consumption from wall?

Made you a video!

https://youtu.be/H_JyJxHVhQw

Claymore is not bad but Phoenix is better!

How does claymore performs on Radeon VII with all your tweaks?