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

Any new hints on the "unknown error" problem with the GTX 1060? I have lowered the mem OC a lot now and running at 24mh, but it is still causing the error to pop up. But if it caused a restart of the whole rig after some time before, now it is running stable with errors. However the hashrate on the cards with errors has jumped up to 24.65 for some reason. 

   We have made some changes in anti-debug code in PhoenixMiner 3.1, which should solve (hopefully) most of these problems.

   If you put the epools.txt file in the same folder as the miner (or in the same folder as the config.txt file), the miner will find it and read it without any additional options. We will add options to specify alternative names for the config and epools files in the next version.

   Yes, this is the preferred way because even with all measures to make the auto-tuning reliable, if Windows starts messing with the GPUs during the auto-tune process, the results may be sub-optimal. Just don't forget to re-run auto-tune if you upgrade the drivers, or the miner itself, or if you change your OC settings, or mod the BIOS.


   Well, while ultimately the pool-side hashrate is all that matters, we only use the reported (local) hashrate when we working on the kernels because the former can be very unstable and prone to random ups and downs due to good/bad luck hitting the shares. Our test rigs are running more than 700 MH/s in total and even so, we have a few perecents ups or downs on pool-side hashrate in the matter of week or so, without any changes from our side, so there is that.


   Thank you for using our miner, we will continue to improve it!
   First, the OC settings of Phoenix doesn't work reliably on drivers older than 18.x.x. If you are using 18.x.x drivers, also note that the minimum and maximum fan speeds are subject to limitations from the GPU BIOS.
   Second, we don't plan to go open-source until some time after we stop working on improvements (which won't any time soon). Two of us are in the process of winding down their day jobs to in order to focus working on the miner and they wouldn't do this if the income is unstable and they can't support their families with it. While we appreciate that a lot of miners will continue to pay the devfee if it is optional, some of us has no so good experince with such "donationware", which ultimately fails to generate any meaningful revenue.

  Yes, unless you have specified explicit log file name with the -logfile command-line option. See the documentation for this option in the first post of this thread for more information.

   Please try the following:
   - increase the page file size to 32 GB (10 x 2.6 GB per DAG plus a few GBs for Windows)
   - try using -amd option to see if the rig starts without the Nvidia cards
   - try using the -lidag command-line option and/or the -gser command-line option to decrease the intensity during or serialize the DAG generation

    It is already late because of the Linux support. Ideally we would like to release 3.1 for both Windows and Linux (at least in alpha form for Linux) but if the delay becomes too big, will release the Windows version first.

   There is nothing much to optimize for solo mining (it's just a different network protocol). Such a big difference is certainly quite strange and most probably attributable to huge swings with the CLO difficulty. We don't follow CLO closely, but bear in mind that the smaller coins with volatile price could have huge difficulty swings in small time thanks to services like nicehash, which throw huge hashrate when the price increases and thus increase the difficulty.

   Sorry, the OC options (including the power limit) doesn't work on Nvidia cards yet. We will implement them in the future.

   You have to increase the page file size more as the DAG size continues to increase with each new DAG epoch. With 12 GPUs and DAG size about 2.6 GB, you better set the min size to 36 GB (or set both min and max to 40 GB).

  Generally all drivers in the 18.x.x branch give almost identical performance. You may also try -clkernel 2 (if you are using AMD cards) because some cards give more stable and/or higher hashrate with these kernels instead of the default kernels.

   It's not the devfee, it is less than 0.01 GH/s in your case. The stale shares also dosn't explain this. Your effective hashrate shouldn't be less than 1.15 GH/s at the worst. Most possibly this is bad luck. Check the effective hashrate reported by the miner and compare it with the effective hashrate shown by the pool.


   There are some "doctored" drivers that can be found online but we don't recommend using drivers with unknown origin, unless the machine is very well isolated from anything important and is used only for mining. The other option with Win7 is to use the blockchain beta drivers.

   Frankly, there is no reason to keep Windows Update working on a dedicated mining rig. Just disable the Windows Update service in the Services control panel and forget about the stupid Windows updates. Of course, if this isn't a dedicated mining rig, this is not such a great idea.

   Thank you for reporting this. We have ASUS Strix RX480 and the fan control works fine on them. Try to set only -fanmax and -tt (without -fanmin).

   Thanks for the nice words!
   Wow, does it work on 1070/1060 too?! We were under the impression that the pill works only on GDDRX5 memory (1080Ti and 1080). We are running it on a mixed Nvidia rig with 1070,1070Ti, and 1080Ti and while the effect on 1080Ti is dramatic, the 1070/1070Ti doesn't seem to be affected at all.

   We were definitely thinking about this back when the pill was first released but since it works with PhoenixMiner too we decided against this. We will get back to this at some point but as it alters the timings rather aggressively, so we hesitate to do this lest there is some kind of long-term degradation on the GPU itself (there is very low probability that this is the case but we can't be cavalier with the equipment of our clients).

  That's what is causing the delay of 3.1  


   There are a lot of messages like this but on the other hand we are running 3.0c for more than a month without any problems. Granted, our rigs are more conservatively clocked and with too much power capacity but still we are trying to understand what is going on with these cases. The fact that nothing is logged in the log doesn't help much.

   Reading regularly but no time to answer too often as we try to push 3.1 out of the doors, and frankly the technical support is the least favorite part of the job for any programmer

   We are using the pill with GTX1080Ti without any problems (54 MH/s). Try to decrease the memory overclock a little to avoid crashes.

This miner is good but unfortunately it crashes while using EthEnlargement pill on GTX 1080. The gain is about 10 MH per card with Claymore. It will be good if you include the option to overclock memory on GTX1080 cards in your next release.

Yap, I'm using 2.9e and works best for me too... With 3.0c having problems everyday, and not sure why..