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

You can't run a bat file as admin.

Use trex miner latest version works fine and better then PM

https://github.com/trexminer/T-Rex/releases

In the NVDIA driver version above 440, using the "-li" or "-gpow" parameter will cause the CPU usage to be too high, please check

Guys,
I am using P106-100 mining cards. When start up got such errors... Anybody can help ?

https://imgur.com/HS0jgyn

Thank you for sharing, will be cool get this speed without bios mod but still good that people share. soon Phoenix will implement straps for polaris card then PM will be best miner on the planet earth.... waiting....

For all !!!

Radeon™ RX 580 GAMING 8G MI 31.9Mh Driver 20.4.2 WIN10, Temp 56-58, MSI Aft. Fan 60%, Bios mod.

PhoenixMiner.exe -pool your -wal  your add -pass x -worker your -rxboost 1 -log 0 -retrydelay 1 -ftime 55 -tt 60 -tstop 70 -tstart 65 -fanmin 30 -Rmode 1 -cvddc 970 or your -mvddc 970 or your -cclock 1175 -mclock 2100 -fret 1 -rate 1 -coin etc
pause

Without fanaticism, you can do more if you experiment.

Experiment!!! Good LUCK!!!

Thanks i'll try again with other drivers. I have 8GB on all my rigs now (since previous issue)
I'm on win7 however maybe this could be an issue ?

Hello,
I have some systems with rx580 windows server 2016 and driver 17.11.1.

The miner does not set vddc and mvddc correct and also the fan speed lags behind temperature so the cards get to 80 degress and shut down.

By comparison if i set the miner to claymore the settings are applied correctly and it works like normal.

This is not a new problem, i've had this for a long time and that's why i kept using claymore.

hello
i use hiveos. i want to use rxboost. but there is a error in log:
but PhoenixMiner run as root. what can be problem? what can i do?

Hello, after my test, it is not in WINDOWS10, but in NVDIA driver version above 440, using "-li" or "-gpow" parameter will cause high CPU usage, please check

note sure why,

everytime i try to set the voltage or ram speed, i stuck at 25MH/s, need to use pixel patcher to reset the speed

using rx 580 8GB

   Not yet, but we received both 3080 and 3090, waiting for 3070. After the ETCHash work is finished, we will switch focus to the new GPUs.


   We can't reproduce this problem. Please tell us what GPU you are using, and the full command line (plus config.txt, if you are using it). Please note the following:

• -li should not be used together with -gpow - pick one or the other
• If you are using -gpow, make sure that -mi is not 0 or any other small value - it must be at least 6-7
• If you are using your main PC with your main GPU for mining, just add -mi 0 and do not use -li or -gpow - this will allow relatively smooth work on the display while the card is mining. Of course, the hashrate will be lower but you can't have both high hashrate, and quick to react GPU

   Yes, there will be Linux support for -straps too.



    6800/6800XT are not supported with native kernels - we don't have either card yet, so the miner falls back to the generic kernels, which are slower and produce more stale shares. Additionally, NiceHash just rejects all stale shares, and that is exactly what you are seeing. You should add -stales 0 when mining on NiceHash to avoid sending known (to miner) stale shares that will be rejected anyway. In order to minimize the stale shares when mining with the generic kernels, you may try to lower the mining intensity -mi to 10, 9, or even lower value. This will lower the speed somewhat but with 10-12% stale shares, it should be worthwhile trade off.




    In our test rigs all is fine even at epoch 400 - 1070Ti mining with over 30MH/s. If you are running Windows, try using older drivers (in our test rigs with 1070Ti we have drivers 397.64, and 456.71 - both work fine). If you are running Linux, you may try to add use 8 GB RAM on your rig, if you are running only 4 GB RAM now.



    Most probably mixed-up drivers. Remove the drivers with DDU, then check if they are really removed - they should be listed only as "Microsoft Basic Display Adapter" not as Radeon .... If necessary, run DDU again until you see only "Microsoft Basic Display Adapter"s in the Device Manager, only then install the new drivers.




   This is intentional - do not worry about it, the miner will force -eres to 0 for the next few epochs. The reason is as follows: there are two methods to create and organize the DAG buffer on AMD cards: the first one is better as it provides slightly higher hashrate, and slightly lower power usage. However it stops working when the DAG size is over 3.9-4 GB, and we are forced to use the second method. The exact limit depends on the drivers but eventually (around epoch 379-384) even 6GB and 8GB cards will have to use the second method. We are disabling the DAG pre-allocation (i.e. forcing -eres 0) in order to be able to use the first method as long as possible. Once the limit is crossed, the second method will be used and -eres will work again as expected.




   The errors are pretty clear - you have to run your .bat file with the "Run As Administrator" and make sure that EIO.dll, EIO.exe, and IOMap64.sys from the PhoenixMiner package are in the same folder. It is not enough to just copy the PhoenixMiner.exe from the new package if you want to use the "-rxboost" option.



   Try using -daglim with lower values  (the default is 4023). See the other recommendations for 4 GB cards in the first post of this thread.




   You need to run PhoenixMiner 5.2e, not the older version 5.1c.





   Try using newer drivers (20.5.x or later) and PhoenixMiner 5.2. However eventually (after several weeks at most) even the 8GB cards will have to switch to second method for DAG generation and organization as explained above. We are looking for a ways to remove this additional inefficiency caused by the big DAG buffer, but it seems that it will be hard to avoid. The good news is that it is not getting worse once the limit is crossed - the hashrate at epoch 400 and 450 is almost the same, the same goes for the power consumption.



   Unfortunately, no. We tried a lot of things, including some very clever tricks to increase the locality of memory accesses and lower the pressure on the TLB cache but the result was even worse than before.







  As explained above, nicehash rejects all stale shares. We can discover only some of the stale shares, but not all because only the pool itself decides which share is stale. In your case even -stales 0 won't make a big difference because only one of the rejected shares was discovered to be stale by the miner itself.





   Try using -fcm 2 or newer drivers. -tt with target temperature should work without problems. If it still doesn't work with the latest drivers, send us a log file to diagnose the problem.





   You only need to run it as administrator if you are using -rxboost or -straps. Check if the .bat file works normally (when not run as administrator) first. To diagnose possible problems, you can also open the "Command Prompt" as Administrator (you should see Administrator:Command Prompt in the title bar) and then run the .bat file from there to be able to see any errors.





   Try using -daglim with lower values for the last GPU (the default for Windows is 4023). In your case use -daglim 1,1,1,4016 to set the DAG limit for the last card to 4016MB and the first three will be on auto (4023MB).





   Not yet, will be implemented in a future version. For now, you may try -mt 2 -rxboost 1 which should give you a good speed up if the cards are not modded.





   From our testing only the Polaris memory controller benefits from the dual DAG buffer of the turbo kernels, there is no speed up on Vega, or Navi. We haven't tested RX6800 yet but it is unlikely that it will provide more speed with dual DAGs as it seems quite similar to Navi in this respect. On Polaris cards with 8GB however, the turbo kernels will work as expected for a long time when using etchash.

19.5.2 has old API and different fan control. The old one(changed around v19.9 ,december 2019?) needed target temperature and currently you need to provide a temp/fan curve.
try using 19.9.2 or 20.4.1

3 - Yes. must give fans/temps curve to the driver, use overdriven tool 0280 - the control is now weird, set above 80% for 80C and about 50% for 65C depending on your conditions and cards.

when etchash is released and dag size is the  below 3gb again....can I then use turbo kernel on 5700 8gb and boost hashrate?

interresting question for the new amd 6000 series as they all have 16gb ram. must take any hashrate advantage of that huge memory

does the straps command work for rx cards ? right now i have to ruin claymore and phoinex in tandem and i hate it.

claymore for straps and phoiniex cuz its more stable

It is not the cause of windows10, but the use of the "-gpow" and "-li" parameters under the drive of NVDIA430 and above will cause high CPU usage. Can this problem be solved?

Hey... me again ...

https://prnt.sc/voss0n

I don't know what's wrong with hashrate GPU 4... I'm using PH 5.2e and 20.4.x drivers (1 rx 570 4 gb and 3 rx 580 4 gb). That one is rx 580 (gpu 4). Compute mode enabled, OC, changed riser, Windows 10... etc...

After starting the .bat, no more than 5 minutes pass and it indicates some problem with the threads.  My head will blow up

Regards

what's the hashrate situation?

Hello, i am sure this question was asked a lot of times - but i never needed it

i was just running PM miner since it exists with not much overtuned cards and it always worked without issues!

now i wantes to run it as an admin ,- in windows i am logged in as an admin, -but to run the bat file as an admin - after starting it says this is not an internal command?

what do i make wrong?

THX