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

Loving Phoenix - 3 rigs, combination of XFX RX570's and RX580's.   Definitely more stable than claymore with fine tuning.

Question regarding -fanmin and -fanmax?

I used to run and set everything with Afterburner and claymore, including manual fan setting.
I set everything on one rig using Afterburner to 65% fan
Then, I stopped afternburner, started up Phoenix with command line addition of "-fanmin 75."
The speed still stays at 65 on all cards in the rig
Any thoughts?

DEVFEE and open source:

Also, any thoughts about making this public domain open source?
I would think that even at 0.65%, your Devfee should have more than paid for itself at this point.
How long do you want to keep it private and collect fee?

If it were me, I'd make it open source, make -devfee an option, and if we love it, have no problem setting a fee.   Certainly, I'd pay the fee (especially if I can control it)
Seems like if it were open source, people would be happier to compile it, and trust it as trustworthy.
It would help with adoption of the Phoenix Miner for the masses.

Hashrate is very stabel in 2.9e and in 3.0c. But "Average Hashrate for last 6 hours" in nanopool statistics page (https://eth.nanopool.org/account/0x...) for 3.0 typically show values less then reported hashrate and "Calculator" tab on this page shows about 0.36 ETH per month, but with 2.9e I have typically "Average Hashrate for last 6 hours" bigger then reported hashrate and calculator shows nubers bigger on 0.1 ETH per month. So if 3.0 shows 0.3x ETH per month, 2.9 shows 4.x ETH per month.

My command line for 2.9 and for 3.0 is:

set miner_params=-nvidia -cdm 2 -cdmport 3333 -cdmpass 12345 -minRigSpeed 188 -rmode 2 -tstop 65 -tstart 40 -logsmaxsize 0 -nvf 2

Thanks. I have 39 amd 570 (3 rigs à 13 gpu).
Raised total speed from 1208 to 1213 with phoenix with autotune. Havent tried manually adjusting yet.

The speed was more stable with claymore (1208 mh/s). With phoenix it is from 1210-1213.
And the speed is different from each time the miner restarts due to auto-tune. Maybe it is better to write down the best settings and set the tune manually.

Dr. Phoenix,
Thanks for the great product.  I've found it faster and more reliable than the competition.

My .bat file points to an alternative config file.  Instead of specifying pools in my config.txt is there a way I can point to the epool.txt file?

Thank you.

   This shouldn't happen with these drivers (we have run exactly the same card with the same drivers and it doesn't behave like that). However we have experienced an MSI 570, which had similar problems even with the stock BIOS. Eventually the MSI stopped working completely unless it is the only card in the rig. It's probably some kind of BIOS problem but we can't be certain.

   Thanks a lot, we are glad it works fine for you We are working hard on improving the hardware support. A lot of the devfee goes towards purchasing and testing all kinds of GPUs to be certain that they are working fine with PhoenixMiner but some of the problems rear their ugly heads only after extended usage, or with certain driver/Windows version combinations.

   Support for Linux (finally), and some interesting optimizations in the kernels.

   This message means that your drivers doesn't support AMD large memory pages (a.k.a. Compute mode) and you will probably get low hashrate on the current DAG epochs. You have to either use drivers 18.x.x (recommended), or the blockchain beta drivers (only recommended if you are on Windows 7, as the official Windows 7 drivers doesn's support Compute mode). If you are mining Pirl, or any other low-DAG coin this doesn't matter but for ETH and ETC the hashrate drop without Compute mode is devastating.

   Did the -cclock -cvddc -mclock -mvddc options work for you with 2.9e? Also, make sure that you are using a 18.x.x driver.

   Sorry for the inconvenience. We will fix this in the next version, where there will be an option to avoid resetting the OC settings at shutdown. This is one of these things that never happens on our rigs because the PSU(s) are well above 150% of the needed power to avoid any hardware instabilities (it would be hard to determine if a crash is caused by the hardware, or a software bug otherwise).

   Make sure that you are running this for at least 24 hours. After at least 24 hours there shouldn't be such a big difference. If the problem continues, switch to another pool because this is not normal in the long run.

   What driver version you are using (18.x.x is required for the hardware control options to work reliably)? Small difference is not a problem (e.g. -fanmax 55 but you are seeing fan speed at 57%).

   You just have to wait about five minutes for the auto-tune to finish and you will get the final hashrate. Also, you can try the -clkernel 2 and see if it gives higher hashrate (after it finished the auto-tune process). Once you figure out the best -gt values you can press 's' in the console window and copy them to your command-line to avoid performing auto-tune each time when you restart your rig.

   We will add support in the next version. In the meantime, you can set -coin clo (or some other new coin with low DAG epoch) to avoid long DAG generation.

  This is on our TODO list but no guarantees that it will happen in the next version. Currently there is a limit of three consecutive rejected shares before switching to the next pool but there is no limit for restarting.

   There is always something to improve. Right now we are focused on the Linux version, and on finding ways to further increase the mining profitability.

  Yes, you just press 7 and it will pause GPU7. Another press on 7, and it would resume mining on GPU7. Pressing p pauses/resumes the whole miner and is independent from the pausing/resuming of the individual GPUs. For example, if you pause GPU7, then pause the whole miner, then resume the whole miner, the GPU7 will still remain paused until you resume it by pressing 7 (or by restarting the miner).

You will see the corresponding message(s) in the console too:

  We are definitely working on these but the focus for the next version is elsewhere. As for the dual mining, it is also coming but ETH +  CryptoNight is not on the cards for now.

   The option will be added in 3.1 for sure.

    Could this be some form of Debugger detected error (since there isn't anything in the log)? We have made some improvements in the anti-debug code, which should lower the time when it "freaks out" without any good reason.

   We have a few GTX970s - you have to use Windows 7, and older drivers, and you can only mine low DAG coins like Pirl, Akr, etc. Mining ETH and ETC is out of the question as the performance drops like a stone with the larger DAGs with GTX970. Also it is quite a fight to get any decent hashrate from GTX970 under Windows 10.

   No, ethermine works fine with both -proto 3 and the default (which is -proto 2). There is no upside in running one over the other (there was in the past but no more).

   Finding of the best overclock value automatically is nice in theory but hard in practice as in many cases the failures are not graceful (i.e. not just incorrect shares but outright Windows crashes, etc.). Perhaps it could be implemented in the future but with hard upper clock limit, and with a lot of caveats and warnings.

   As for the lower hashrate of one of your GPUs - usually it has different memory timings than the others. Also, even if you don't have a display attached, if you don't have an integrated Intel video with HDMI plug (and even in such case, make sure that you have made the iGPU the primary GPU in the BIOS), one of your GPUs would still be used more by Windows and designated as the "primary" GPU.

  If this happen again, check if the same GPU (GPU6), shows the first error. If so, lower the memory overclock of GPU6.

   Sorry about that. We will have a fix for this in the next version, where this error shouldn't happen so often.

   You can do this with the current version by specifying the file name as the only parameter:
   And if you run without any parameters, it will load config.txt.

   1. Probably some mishap with the access rights in this particular folder.
   2. The hashrate is often unstable, and we are using finer-grained tuning parameter, so we want to be sure that we have found the best -gt value. You will only need to run auto-tine when the miner restarts. If you are restarting your miner frequently, just copy the best -gt values found by the auto-tune (you can press the 's' key in the console to see them) and paste them in your command line. When the -gt values are specified, there will be no auto-tune unless manually requested by pressing the 'z' key in the console.

   What is the difference between the reported average hashrate in 2.9e and 3.0? Perhaps this is an issue of unstable hashrate. You can try -clkernel 2 (if you aren't already using the alternative kernels) and see if they will give you more stable average hashrate. On some cards we have observed random-ish drops in hashrate in the normal kernels, which are missing with alternative kernels.

Post your config file, that should help.  If one of the members can't help you Dr. Phoenix will be along in time.

The params won't work in v2.9 or 3.0?
Mine work fine, here's my .bat file

3.5 days ago I have reverted from 3.0c to 2.9e. I use nanopool for eth. Basing on statistics from pool I have result some better now.

Can I get a response because these parameters in the combo line in the .bat file will not work -cclock -cvddc -mclock -mvdd , And how to solve it
I try the phoenix miner v2.9e upgrade to 3.0C
I have Amd xfx rx580 8gb gts xxx 8xcard in Rig

Just started using this miner now. Seems good so far.

1. When starting mining the line "unable to open log file etc.." shows up for a few seconds before it starts mining.
What is that about?

2. Also using the autotune. How come claymore autituning takes a few seconds and yours a few minutes?

PhoenixMiner 3.0c
What are the stable drivers for MSI Geforce GTX 1060 6Gb Gaming X ??7

I suggest the next version should have an option to choose which config file is used. If not specified, it automatically loads the default config.txt

Hi guys

working good with this bat on nvidia GPU

TIMEOUT 25
@echo off
setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
PhoenixMiner.exe -pool ssl://eu1-etc.ethermine.org:5555 -pool2 ssl://eu2-etc.ethermine.org:5555 -wal 0x56786109c0f2e0d3e0a8bb29394564370a23d.etc2 -coin etc -proto 3 -cdm 2
pause
@echo on

Different GPUs may or may not hash as fast as others. Part of it is just silicone lottery at play, but if you have different VRAM you will tend to have different hashrates. Even the exact same brand and model of GPU can have different memory installed on it.

PhoenixMiner_3.0c all rigs  AMD r390+win10 or win7  FATAL ERROR: Debugger detected 


setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
PhoenixMiner.exe -pool stratum+tcp://daggerhashimoto.eu.nicehash.com:3353 -wal my_btc_wallet -pass x -proto 4 -stales 0 -amd

ps
working only on NVIDIA cards

You have a round about eta on dual mining yet?

What are the stable drivers for MSI Geforce GTX 1060 6Gb Gaming X ?

Driver 398.18 miner 3, what's the problem?

2018.06.30:18:12:14.958: eths Eth: Received: {"id":6,"jsonrpc":"2.0","result":true}
2018.06.30:18:12:15.747: main GPU1: 56C 46%, GPU2: 58C 48%, GPU3: 55C 45%, GPU4: 55C 45%, GPU5: 55C 44%, GPU6: 49C 39%
2018.06.30:18:12:19.606: main Eth speed: 149.125 MH/s, shares: 6/0/0, time: 0:04
2018.06.30:18:12:19.606: main GPUs: 1: 24.668 MH/s (0) 2: 25.003 MH/s (2) 3: 25.003 MH/s (0) 4: 24.999 MH/s (0) 5: 24.999 MH/s (3) 6: 24.453 MH/s (1)
2018.06.30:18:12:20.422: GPU6 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.422: GPU6 GPU6 search error: unspecified launch failure
2018.06.30:18:12:20.450: GPU4 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.450: GPU4 GPU4 search error: unspecified launch failure
2018.06.30:18:12:20.481: GPU5 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.481: GPU5 GPU5 search error: unspecified launch failure
2018.06.30:18:12:20.497: GPU2 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.497: GPU2 GPU2 search error: unspecified launch failure
2018.06.30:18:12:20.499: GPU3 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.499: GPU3 GPU3 search error: unspecified launch failure
2018.06.30:18:12:20.513: GPU1 CUDA error in CudaProgram.cu:329 : unspecified launch failure (719)
2018.06.30:18:12:20.513: GPU1 GPU1 search error: unspecified launch failure
2018.06.30:18:12:20.544: wdog Thread(s) not responding. Restarting.
2018.06.30:18:12:24.685: main Eth speed: 99.168 MH/s, shares: 6/0/0, time: 0:04

It doesn't need to have a monitor attached.  GPU0 will process graphic requirements for the system even if you're RDSing in.  I keep an old HD5450 attached to my main PCIE-16 slot so it assumes all the graphical duties.

Any news on the update or beta version?

I assume Nvidia finding of best overclock value in next release.


I always wonder why one of my GPUS has lowerst clock compared to others.
GPU0 us always 28 sumfin, where others 31 on RX580s.
There no monitors attached as some people think. \Just dont understand it?