...
FATAL ERROR: Debugger Detected
i tried with and without the -amd
Hello
I needed to install the drivers new. I use -amd. I use RX480, blockchain driver and 3.0c. Stopped working last friday.
FATAL ERROR: Debugger detected
What can I do? Claymore is working.
Thx for helping
We have made some changes in anti-debug code in PhoenixMiner 3.1, which should solve (hopefully) most of these problems.
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.
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.
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.
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.
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
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.
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.
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.
Does the miner create a new logfile when it is closed and starts again?
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.
Hi.
phoniex miner crashes just after starting load gpu log file doesnt give too much info.here is the log:
2018.07.04:11:54:56.713: main Phoenix Miner 3.0c Windows/msvc - Release
2018.07.04:11:54:56.713: main Cmd line: -pool etc.arsmine.net:8008 -wal 0x1c9cfc8a55dc86cee1c07a354593428d8894ad30 -worker Robert -pass x -coin etc -rmode 1 -wdog 1 -log 2 -ftimeout 200
2018.07.04:11:55:10.755: main Available GPUs for mining:
2018.07.04:11:55:10.755: main GPU1: Radeon RX 570 Series (pcie 1), OpenCL 2.0, 4 GB VRAM, 32 CUs
2018.07.04:11:55:10.756: main GPU2: Radeon RX 580 Series (pcie 2), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.07.04:11:55:10.756: main GPU3: Radeon RX 570 Series (pcie 6), OpenCL 2.0, 4 GB VRAM, 32 CUs
2018.07.04:11:55:10.756: main GPU4: Radeon RX 570 Series (pcie 7), OpenCL 2.0, 4 GB VRAM, 32 CUs
2018.07.04:11:55:10.756: main GPU5: Radeon RX 570 Series (pcie Cool, OpenCL 2.0, 8 GB VRAM, 32 CUs
2018.07.04:11:55:10.756: main GPU6: Radeon RX 570 Series (pcie 9), OpenCL 2.0, 4 GB VRAM, 32 CUs
2018.07.04:11:55:10.756: main GPU7: Radeon RX 570 Series (pcie 10), OpenCL 2.0, 4 GB VRAM, 32 CUs
2018.07.04:11:55:10.756: main GPU8: GeForce GTX 1070 (pcie 11), CUDA cap. 6.1, 8 GB VRAM, 15 CUs
2018.07.04:11:55:10.756: main GPU9: GeForce GTX 1050 Ti (pcie 12), CUDA cap. 6.1, 4 GB VRAM, 6 CUs
2018.07.04:11:55:10.756: main GPU10: Radeon RX 580 Series (pcie 13), OpenCL 2.0, 4 GB VRAM, 36 CUs
2018.07.04:11:55:11.338: main ADL library initialized
2018.07.04:11:55:11.375: main NVML library initialized
2018.07.04:11:55:12.143: main Listening for CDM remote manager at port 3333 in read-only mode
2018.07.04:11:55:12.143: main Eth: the pool list contains 1 pool
2018.07.04:11:55:12.143: main Eth: primary pool: etc.arsmine.net:8008
2018.07.04:11:55:12.143: main Starting GPU mining
2018.07.04:11:55:12.143: main Matched GPU1 to ADL adapter index 32 (method 1)
2018.07.04:11:55:12.425: main GPU1: Created ADL monitor for adapter 32; overdrive version: 7
2018.07.04:11:55:12.426: main GPU1: using AMD driver ver 18.6.1
2018.07.04:11:55:12.426: main Matched GPU2 to ADL adapter index 80 (method 1)
2018.07.04:11:55:12.855: main GPU2: Created ADL monitor for adapter 80; overdrive version: 7
2018.07.04:11:55:12.855: main GPU2: using AMD driver ver 18.6.1
2018.07.04:11:55:12.855: main Matched GPU3 to ADL adapter index 64 (method 1)
2018.07.04:11:55:13.369: main GPU3: Created ADL monitor for adapter 64; overdrive version: 7
2018.07.04:11:55:13.369: main GPU3: using AMD driver ver 18.6.1
2018.07.04:11:55:13.370: main Matched GPU4 to ADL adapter index 96 (method 1)
2018.07.04:11:55:13.752: main GPU4: Created ADL monitor for adapter 96; overdrive version: 7
2018.07.04:11:55:13.752: main GPU4: using AMD driver ver 18.6.1
2018.07.04:11:55:13.753: main Matched GPU5 to ADL adapter index 112 (method 1)
2018.07.04:11:55:14.328: main GPU5: Created ADL monitor for adapter 112; overdrive version: 7
2018.07.04:11:55:14.329: main GPU5: using AMD driver ver 18.6.1
2018.07.04:11:55:14.329: main Matched GPU6 to ADL adapter index 48 (method 1)
2018.07.04:11:55:14.627: main GPU6: Created ADL monitor for adapter 48; overdrive version: 7
2018.07.04:11:55:14.627: main GPU6: using AMD driver ver 18.6.1
2018.07.04:11:55:14.627: main Matched GPU7 to ADL adapter index 16 (method 1)
--------------------------------------------------------
Any help? 2.9d works with out any problem.
Many thx in advance
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
When is next version due??
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.
I don't know why but I have tried many times: with 800-850Mhs, I mine solo CLO at altpool.pro, if I use Phoenix or Bminer, I find 0 - 1 block/24h, if I use Claymore, I find 3 - 5 blocks/24h. Is Phoenix not optimized for solo-mining?
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.
for me power limitation doesn t work. I tried adding -powlim -20 or -li or -gpow but
in my stats alwais at 100% the utlization. It makes my pc lag. I have a 1050 ti and w7 64 bit
What i have to write in the config?
Sorry, the OC options (including the power limit) doesn't work on Nvidia cards yet. We will implement them in the future.
Lately I am getting a clEnqueueNDRange(-4) error on GPU 12. I only have 12 Sapphire RX570 GPUs attached to my rig.
My rig has been humming without any errors for many months. This just happened lately like since 2 weeks back. Any ideas how to solve this?
My virtual memory is already set to min 24000 and max 36000
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).
which 18.x driver is best for phoenix?
Just tried 18.6.1 on 3-card pc, and all cards started to mine with 16MH - both with Claymore and Phoenix...
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.
2% stale shares.
Maybw its devfee kicking in.
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.
win7 ...
It seems there is no way to enable compute mode under Win7 and later (18.x) drivers.
Tried everything (registry, compute-switch tool) - FB usage stays at 65-68%
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.
Version 3.0c. Fan control seems not to be working properly.
Environment:
Clean installation Windows 10 (1709), no updates.
Drivers - latest (18.6.1)
Card: single Asus ROG Strix RX580 O8G (stock bios, only timings modified)
No any additional software than can interfere with fan control is installed (like Afterburner etc.)
-fanmin 50
-fanmax 100
-tt 55
When miner starts - fans are initially stopped. When temperature rises to 50 and above - fans start working on max speed (maybe not max but high enough). In a few seconds temperature drops below 50 and fans begin to slowdown and finally stop. In a few seconds the sequence repeats.
Tried setting -tt -50 to force constant fan speed - not working.
At the same time it works on Asus Strix RX570 more or less properly. At least asjusts fan speed to keep temperature set by -tt.
I have compared bios bios fan settings for these two cards - they are identical.
It is incompatibility with this particular card or I am missing something?
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).
I just flipped over my 200+ gfx cards to Phoenix miner from Claymore and experienced more stability, less stale shares AND 1.5-2% increase in profits.
Please keep up the good work and i will continue to use your miner.
My farm has about 50% nVidia cards which just a few are 1080Ti.
With OhGodAnETHlargementPill injecting tighter memory timings the 1080Ti whent from 37MH to 54MH.
https://github.com/OhGodACompany/OhGodAnETHlargementPillTo inject new tighter memory timings in to nVidia cards result in a dramatic increase of HashPower in most 10xx serise cards
For example a 1070 can do up to 44MH and 1060 pushes over 30MH (depending on memory type and manufacturer of course)
My suggestion is to reverse engineer the OhGodAnETHlargementPill to find out how it's done and add it to the Phoenix miner.
Adding nVidia memory injection to cover 1050/1060/1070 would make Phoenix miner totally unstoppable.
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.
@ PhoenixMiner
I second the request to reverse engineer OhGodACompany's Ethlargment Pill.... If you follow Kristy, she's stated that the software was card locked for the 1080 & 1080ti but works with the 1060 and 1070.
From what I've put together if someone figures out how to remove the card lock it would detect the 10 series card and set mem timings appropriately (this maybe incorrect info) but regardless it would show how to inject mem timings without flashing the cards with a SPI programmer & pomona clip.
She's under a NDA agreement for the software and from my understanding, cant release it for the 1060 and 1070 until someone else reverse engineers and releases it with or without dev fee. No matter how you look at it it would give you more hashrate on your dev fee and help us compete with what ever FPGA's are out there on ETH and the E3 that's about to ship.
Wolf0 aka OhGodAPet already penetrated your miner to take a look earlier in this thread when Claymore accused you of stealing his kernels, so I think its only fair you open it up to take a look if you haven't already...
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).
please release linux version
!
That's what is causing the delay of 3.1
Hello Phoenix team,
Any update? I seem version 3.0C have some problem, a lot of PP rollback 2.9e
Looks like 3.0c have a lot of problem, I can't get it working for more than two days. 2.9e works perfect for me 🙄
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.
OP are you still out there? Haven’t heard from you in a while.
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
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.
We are using the pill with GTX1080Ti without any problems (54 MH/s). Try to decrease the memory overclock a little to avoid crashes.
