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

prog-pow for ZANO soon ? coin you have a great opportunity

>> Is there any kind of way you can monitor the output of the miner and parse the -gt value and insert it into the config file?

MultiPoolMiner controls the start and stop process of the miner. So it can read data from the API (or from the log) before stopping the miner and store the config data for re-use on later runs.
But to scan the logs does not seem to be right way. Retrieving it from API data should be the way to go.

Oh I did not know you was trying to integrate it into another system. Hmm...  I guess you would need some type of API to get the optimized -gt value and insert it into the config file for the next time it restart its automatically there. Is there any kind of way you can monitor the output of the miner and parse the -gt value and insert it into the config file?

I am the co-developer of MultiPoolMiner (www.multiPoolMiner.io).
Unfortunately your approach is not an option... our software (and similar software based on the MPM core, e.g. NemosMiner, RainbowMiner) requires an all-automatic way with no user intervention.

The one aspect of AMD Mem Tweaker that seems ideally suited to include is the new REF adjustment (aka rxboost in claymore).

It's just a single value so not too complex for the end user, it can offer substantial performance boosts, and unlike the memory timing adjustments it's not specific to any particular memory type.
It also acts independently of BIOS timing mods.

If you don't want to look through the log files, just use the "s" command while the miner is running then copy the output and put it into your config file. Whats in the log file is what is displayed in real time in the CMD window.

Thank you for the hint - that is a valid option. But what if I do not want to have logs???

This is possible, just read your log file and look at the last line that has "current -gt xx xx xx xx" value in the log and put that in your start.bat or what ever you use to start the miner. That is what I did. You can also press "s" while the miner is running and it will tell you what the current "-gt" value is and you can put that in your config. It will also put it in the log file when you do that as well. 

This is the output of "s" while miner is running in the log:


Config Example:

It would be very helpful if the best found auto tuning values were available in the API data, or even better stored in a human readable file. PM could then just apply that data on the next start.

no, i am not complaining about its slowness.
the problem is that if gt is not set, auto-tune runs every time gpu starts mining after reaching temp limit.
so, instead of start running at 33MH with already found gt value, gpu starts at 26MH and when it reaches 33 after few minutes, it can reach temp limit again and stop mining.
yes, that is not normal in long term usage, but when it is too hot you have no so many choices.

btw, what do think about starting auto-tuning not from 0 but from user-defined value?
so if most of gpus have the same +/- 1 gt value, you can set, for example, -gt 15, and auto-tuning will try higher and lower values for best performance, and it will take much less time to complete.

   For now - no, it works fine as free standalone program and we don't see much value in integrating it within the miner. However this may change in the future.


   There will be full support for the latest Windows and Linux AMD drivers in PhoenixMiner 4.3.


    It is deliberately "slow" (it takes 3-5 minutes on average) in order to get repeatable and reliable results. If the auto-tuning is significantly faster, we will be taking less measurements and as a result the "best" GT found may not be optimal. To avoid the problem you are running into, you can run auto-tune again after the temperatures has stabilized. In order to do that, you need to press the 'z' in the miner console window.


   If our translation is correct, what you are observing is that PhoenixMiner switches to the secondary pool when the primary pool fails. PhoenixMiner always reads epools.txt file if there is such file, and adds the pools from it to the pools specified on the command-line. The epools.txt file that is supplied with the miner contains an example pool and address, which is used as fallback pool if you don't change it to your own. Here is what to do in order to fix the problem (you need to do only one of the following):
  1) Delete or rename the epools.txt file which is in the same folder as PhoenixMiner.exe
  2) Or, edit the epools.txt file and change the pool and wallet to your own secondary pool and wallet


  Unfortunately, no. There is no almost no difference in the way PhoenixMiner threats 470 and 570. The only possible explanation is that 470s are probably older and may experience some performance degradation, and may not be stable anymore on the clocks and voltages they were stable in the past. You can try to run them on lower clocks (mostly memory) and see if the stability issues remains. Another possibility is that the ambient temperatures are rising, and the cooling may not be enough (or the heatsinks may be clogged with dust, the thermal pads on the VRMs or memory chips may be drying and no longer being effective in conducting heat, etc).

Just wanted to say thanks for the work you are doing. This software is averaging 1-2MH/s faster on each card and is way more stable then claymore ever was for me.

6 X RX570 8GB 1 X RX570 4GB   217MH/s Reported ---  Average @ pool 200-217MH/s.

Hi,
Im on "Phoenix Miner 4.2c Linux/gcc - Release build".

And and AMD RX470 I have an issue that after a while (hour) the miners freeze and stops mining.
Its not able to kill it (even with -9).

Restart helps, but to make a restart every hour is akward. This is happening to kinda all RX470. On RX480, 580, .. they are all fine. Same settings and version.
Ive also tried "-altinit -gser 0". Since without it the RX470 soing event start to mining.

Any tips?
(eh, last ethos and miner).

Xoтя бы c пoмoщью oнлaйн пepeвoдчикa бы пepeвeл... Фopyм нa aнглийcкoм языкe.
A пo пoвoдy пpoблeмы... Лoг пpeдocтaвь. Гoлocлoвныe yтвepждeния - нe фaкт...

зaмeчeнн бaг нa пpoтяжeнии 2-3 мecяцeв, Baш мaйнep пepeключaeтьcя нa ethermine pool и кaпaeт нecкoлькo минyт бeз dev fee a пpcoтo caм пo ceбe. пpoиcxoдит этo c пepeoдичнocтью c 3-5 cyтoк. зaмeтить oчeнь тяжeлo.

Undervolt your GPUs, I don't have such a problem.

PhoenixMiner

Please fix support for newer drivers on linux - 19.10, 19.20.
currently miner uses -clnew 0 regardless of clkernel setting.
probably all these kernels can work if there was no check for driver version.

second thing that can be easily fixed - auto-tuning is quite slow and it is running after gpu temp reaching its limit. every time!
there is no need for this. just use gt values found during startup.

thanks in advance

Thanks!

Are you planning on including the AMD Mem tweaker in the next release?

Read this if you can't mine ETH with PhoenixMiner: important message for everyone that is running older versions of PhoenixMiner (before 4.2) - this was already posted here a few times:

IMPORTANT! The versions of PhoenixMiner before 4.2 only support DAG epoch up to 265. ETH has reached epoch 266 already. To ensure uninterrupted operation, please upgrade to 4.2. If you are mining other coins, you can safely disregard this message.

The reason for this limitation is that we need to perform some quite complex calculations for each future DAG epoch in order to increase the hashrate of the optimized kernels. Recently we have added more computational resources and PhoenixMiner 4.2 will work without problems up to DAG epoch 329. We will increase this number significantly (e.g. 400 or more) in the next version.

To answer other questions:

1. Yes, we are working on the next version. There aren't any huge changes however, so we are taking our time to fix any problems, add small missing features, etc. We will probably release the next version shortly after the new AMD 5700 cards are released (they should be out on Jul 7th).
2. You should not upgrade the AMD drivers or let Windows 10 upgrade itself because all current AMD cards are released a long time ago (Radeon VII is the only exception) and there is no upside in upgrading the driver, only downsides (like AMD constantly changing the API for clocks, fans, voltages control, etc.).

This is not good...