Hello Phoenix.
I have a request for the next version of your miner:
The H/s is shown every 5 sec., it is too much for me, filling the screen with unneeded information.
Could you add, when using -gswin, the H/s display change with this value, for example if you use -gswin 5 you see H/s every 5 sec. but if you set -gswin 15 it show every 15 sec.?
And/or add an option to show the H/s only after every received job like in claymore miner?
Thank you.
In 3.0b we have included an option to specify the interval at which to show the speeds (5-30 seconds, or 0 to disable it completely and rely on the detailed stats only, which are shown every 45 seconds).
I am having some issues upgrading to 2.9e. When I use 2.8C on my Vega rigs (Beta Blockchain drivers), I have no issues. If I try 2.9e, I run into this issue:
We had no Vega64s at the time so we couldn't reproduce the problem but according to other uses, it is caused when driver 18.4.x and above is used. Anyway, yesterday we have received the ordered Vega64s and sure enough, the problem appeared right away. It was fixed this morning and the fix will be included in 3.0b, which will be released tomorrow.
Hi comunity !
First at all let me thank you for youre miner, a great job.
Until now I was using PhoenixMiner_2.6 and everything works perfectly.
Yesterday I decided to upgrade to a newer version PhoenixMiner_2.9e.
He works even better 2.6, but, usually my hashrate and only on GPU0 drop to 19-18 and then go back to 30.
May i kindly ask youre help with this problem.
Thank You in advance.
This happens sometimes on the GPU, which is connected to a display (or to a plug, simulating display). The reason is that Windows messes up with the driver. You can try different -clf settings (but only for this card if you don't have similar problems with the other cards). Generally, it is best to use Intel IGP if your motherboard has one, and to put the plug in its display outputs, instead of one of the GPUs.
Hi PM developers. Can you add an additional hot key and corresponded functionality to show in console all parameters used by miner (even if they are not defined in command line and have default values). For example in this way:
param1: value1
param2: value2 (default)
param3: value3
param4: value4
param5: value5 (default)
Thank you
Good idea, it will be added in a future version (maybe even in the final release of 3.0 if there is enough time). Intially, it may not include all options but at least these that are dynamically re-loadable by PhoenixMiner 3.0a by pressing the 'c' key.
Even with 2.5d now I'm unable to run the miner, though I'm starting to think it's something on my end. After further investigation once GPUs are identified in the console the error message: "FATAL ERROR: Debugger detected" is shown immediately before it crashes. So there's some update please ? Or maybe i will back to use my last miner software. Anyway thank you for trying make more chipper dev fee mining.
Usually this is something to do with the drivers. If you are using very old drivers you may try 18.x.x drivers, they work fine for us. Also if you have only Nvidia cards, try to specify the -nvidia option. We will continue trying to refine the anti-debugging techniques but the big step will probably be in the next version (3.1).
Thank you for supporting PhoenixMiner!
Please devs, you are losing a lot of money by not capitalising on linux users. I mine on HiveOS and I have tested Pheonixminer on Win10 and there is no doubt that it is the best ethash miner. There's not much time left for ethash GPU mining, so come up with somethig fast.
Yes, we know
But some of the code is not easily ported to Linux without significant performance issues. We are rewriting it right now (we even foolishly hoped that 3.0 will be the first Linux supporting version) but we are not there yet. Just bear with us a little bit longer. We want the Linux version to be on par with the Windows version before releasing it.
I think author must make Windows 10 1803 April Update compatibility with new drivers.
AMD Adrenalin 18.5.1 driver normal works with Claymrore's miners...
If you are using AMD Vega, the issue will be fixed in 3.0b which will be released tomorrow. Otherwise, please tell us what cards you are using as we don't have issues with 18.5.1 on our test rigs.
Got a weird error today after windows update. See below out of mem error.
Mining Win10 with 6x 1060 6GB and 16GB PageFile. Resolve it finally by increasing the page file to 24GB.
Hope this helps others.
2018.05.27:10:37:56.494: main Phoenix Miner 2.9e Windows/msvc - Release
2018.05.27:10:37:56.494: main Cmd line: -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal XXX -proto 3
2018.05.27:10:37:59.271: main Available GPUs for mining:
2018.05.27:10:37:59.272: main GPU1: GeForce GTX 1060 6GB (pcie 1), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2018.05.27:10:37:59.272: main GPU2: GeForce GTX 1060 6GB (pcie 2), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2018.05.27:10:37:59.272: main GPU3: GeForce GTX 1060 6GB (pcie 4), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2018.05.27:10:37:59.272: main GPU4: GeForce GTX 1060 6GB (pcie 6), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2018.05.27:10:37:59.272: main GPU5: GeForce GTX 1060 6GB (pcie 8), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2018.05.27:10:37:59.272: main GPU6: GeForce GTX 1060 6GB (pcie 9), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2018.05.27:10:37:59.283: main NVML library initialized
2018.05.27:10:37:59.506: main Listening for CDM remote manager at port 3333 in read-only mode
2018.05.27:10:37:59.508: main Eth: the pool list contains 4 pools
2018.05.27:10:37:59.508: main Eth: primary pool: eu1.ethermine.org:4444
2018.05.27:10:37:59.508: main Starting GPU mining
2018.05.27:10:37:59.509: wdog Starting watchdog thread
2018.05.27:10:37:59.509: main Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: QtMiner)
2018.05.27:10:37:59.544: eths Eth: Connected to ethash pool eu1.ethermine.org:4444 (94.23.36.128)
2018.05.27:10:37:59.544: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_login","params":["XXX"]}
2018.05.27:10:37:59.573: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":true}
2018.05.27:10:37:59.573: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.05.27:10:37:59.591: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":2018.05.27:10:37:59.591: eths Eth: New job #7d15954f from eu1.ethermine.org:4444; diff: 4000MH
2018.05.27:10:37:59.592: GPU1 GPU1: Starting up... (0)
2018.05.27:10:37:59.592: GPU1 Eth: Generating light cache for epoch #189
2018.05.27:10:37:59.594: GPU2 GPU2: Starting up... (0)
2018.05.27:10:37:59.595: GPU3 GPU3: Starting up... (0)
2018.05.27:10:37:59.598: GPU4 GPU4: Starting up... (0)
2018.05.27:10:37:59.601: GPU5 GPU5: Starting up... (0)
2018.05.27:10:37:59.602: GPU6 GPU6: Starting up... (0)
2018.05.27:10:37:59.711: main GPU1: 38C 0%, GPU2: 35C 0%, GPU3: 37C 0%, GPU4: 46C 0%, GPU5: 42C 0%, GPU6: 42C 0%
2018.05.27:10:38:00.985: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":
2018.05.27:10:38:00.985: eths Eth: New job #992bc07d from eu1.ethermine.org:4444; diff: 4000MH
2018.05.27:10:38:02.597: GPU6 GPU6: Allocating DAG (2.49) GB; good for epoch up to #191
2018.05.27:10:38:02.625: GPU5 GPU5: Allocating DAG (2.49) GB; good for epoch up to #191
2018.05.27:10:38:02.625: GPU1 GPU1: Allocating DAG (2.49) GB; good for epoch up to #191
2018.05.27:10:38:02.662: GPU2 GPU2: Allocating DAG (2.49) GB; good for epoch up to #191
2018.05.27:10:38:02.666: GPU4 GPU4: Allocating DAG (2.49) GB; good for epoch up to #191
2018.05.27:10:38:02.681: GPU6 GPU6: Allocating light cache buffer (39.9) MB; good for epoch up to #191
2018.05.27:10:38:02.715: GPU1 GPU1: Allocating light cache buffer (39.9) MB; good for epoch up to #191
2018.05.27:10:38:02.756: GPU5 GPU5: Allocating light cache buffer (39.9) MB; good for epoch up to #191
2018.05.27:10:38:02.780: GPU4 GPU4: Allocating light cache buffer (39.9) MB; good for epoch up to #191
2018.05.27:10:38:02.805: GPU2 GPU2: Allocating light cache buffer (39.9) MB; good for epoch up to #191
2018.05.27:10:38:02.895: GPU6 GPU6: Generating DAG for epoch #189
2018.05.27:10:38:02.906: GPU3 GPU3: Allocating DAG (2.49) GB; good for epoch up to #191
2018.05.27:10:38:02.941: GPU1 GPU1: Generating DAG for epoch #189
2018.05.27:10:38:02.969: GPU5 GPU5: Generating DAG for epoch #189
2018.05.27:10:38:02.992: GPU4 GPU4: Generating DAG for epoch #189
2018.05.27:10:38:03.020: GPU2 GPU2: Generating DAG for epoch #189
[color=red]2018.05.27:10:38:03.099: GPU3 CUDA error in CudaProgram.cu:377 : out of memory (2)
2018.05.27:10:38:03.103: GPU3 GPU3: CUDA memory: 6.00 GB total, 4.97 GB free
2018.05.27:10:38:03.103: GPU3 GPU3 initMiner error: out of memory
2018.05.27:10:38:03.597: wdog Thread(s) not responding. Restarting.[/color]
2018.05.27:10:38:04.557: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
2018.05.27:10:38:04.557: main GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0) 3: 0.000 MH/s (0) 4: 0.000 MH/s (0) 5: 0.000 MH/s (0) 6: 0.000 MH/s (0)
2018.05.27:10:38:04.592: GPU6 GPU6: DAG 13%
2018.05.27:10:38:04.650: GPU5 GPU5: DAG 13%
2018.05.27:10:38:04.686: GPU4 GPU4: DAG 13%
2018.05.27:10:38:04.703: GPU2 GPU2: DAG 13%
2018.05.27:10:38:04.744: GPU1 GPU1: DAG 13%
Good thinking, yes it is weird because there should be no need for Windows drivers to always want to map the DAG buffers in the page file. As a rule of thumb, the
page file must be bigger than the size of the DAG multiplied by the number of GPUs plus 20-30% more for Windows itself. In your case (6 x 2.59) x 1.3 = 20 GB
Hi.
i am. using latest phoinex miner.
i have no stale and no incorrect shares but i have around 15 rejected shares in 36hours.
how do reduce rejected shares to minimum? Many thx in advance for your advices...
Rejected shares are usually caused by the pool - usually because it is switching jobs too often or it is too overloaded and can't process the shares in time. 15 shares for 36 hours is more than usual but it depends on the total number of shares and what percent are rejected. We usually get less than a dozen rejected shares per week with about 1 GH/s hashrate from our test rigs on ethermine but on other pools it can be quite different.
Hello, today i first time switched from HiveOS and ethminer to Win10 and Phoenoxminer.
I have one problem, the gpu temp. Is high compared to ethminer in hiveos. 10C high !
Most probably the voltage is not set low enough. Please use GPU-Z or similar too to check the voltages and clocks. If they are OK, check the fan speeds. If you are using AMD cards and relatively new driver (18.x.x), you should be able to do this by the hardware overclock settings of PhoenixMiner itself. If you are using Nvidia cards, you should use MSI Afterburner or some other third party tool to control fans, clocks and voltages.
Hi.
i am. using latest phoinex miner.
i have no stale and no incorrect shares but i have around 15 rejected shares in 36hours.
how do reduce rejected shares to minimum? Many thx in advance for your advices...
lower OC
Thanks mate. will. do
OC doesn't affect rejected shares, only incorrect shares. If you have (a lot of) incorrect shares or the miner crashes, then lower OC.
Hi PM developers. I have found the problem of 999 and 719 errors in my case. It was too big overclocking. I have decreased my MC from +670 to +650 and I forget about any errors during 10 days after this change. So it was not bug of PM. Moreover, my hashrate was decreased on 1 Mh/s, but I have better average mining result and w\o any restarts.
Thank you for reporting this. We knew that this is not a bug because our Nvidia test rigs never crash (but we keep them at pretty low OC settings to be sure that when they crash we have a bug on our hands and not chasing the wind). However we tried to find what could be the reason for higher sensitivity of the new kernels when the overclock is too high. The only thing that made some difference is the new -clf 3 setting but it may also affect the hashrate so your way of lowering the overclock a bit is definitely the best solution.
Hello,
I have 1070 G1 Gaming (Micron memory) and I keep them at 60% TDP, -150 CC and +780 Memory on 2.9e (with MSI Afterburner, I've tried also Nvidia Inspector but now I have a custom fan curve) and it's working fine maybe for few days and after that a restart but I don't care (with 230.2 MH/s for 7 GPU's).
On Claymore 11.6 on 60%, 0 CC and +800 Memory no errors for weeks and working very good but with 226 MH/s.
Now I'm trying on 1 RIG with 2.8C with 60% TDP, -150 CC and +800 to see how long they will run. (I have 231 MH/s for 7 GPU).
I'm still with Windows 10 1709 and Nvidia driver 391.35.
I'm waiting the new version to see how will be.
And yes, I have that error 999 - unable to get fan speed and only for GPU 1 and only on one RIG...:/
That little breackdown it's when I've changed the miner 2.9e with 2.8c.
NanoPoolRegards
999 is almost always caused by too high memory overclock. Check which GPU start showing it first (once it happens on one GPU, the driver is messed and all GPUs start showing it) and lower its memory overlock by 20-30 MHz. This will get rid of it for sure.
Hi all.I think It would be cool if dev added the function of turning off the backlight on gpu. Backlight is useless for mining, if you turn it off then in any case even a small reduction in consumption will be very good, on Linux platform has long been such a function, but is it possible to add to the miner?What do you think about it?Thanks.
This is interesting idea but as far as we know the Windows drivers doesn't provide any API to control the LEDs - each manufacturer has its own private API. Theoretically, it should be possible to reverse-engineer it but its hardly worth the time and money.
tried the 3.0 beta have 6x 1060 GB pulling 30watts total more without hash increase. switched back to 2.9e for now
Shouldn't be happening, there are no changes in Nvidia kernels and no wattage changes in our internal testing. Probably the OC settings are different - check with GPU-Z or something like this.
It wasn't that groundbreaking like it was advertised.
Looking forward to the Linux version, though. Keep it up guys!
Sorry about that, we decided to release whatever features are ready and stable because the gap from the previous release became too long, and because we promised a ne release before the end of the month.
I have installed the new 3.0a.
Running about an hour, new auto tune worked great. Got about .5 mh increase with the new tune.
No increase in temps or power usage.
Running all RX-580 AMD cards.
Thanks PM.
Running smooth.
what about problem "gpu failes to load kernels clcreatekernel (-46) phoenix"
vega56 5x rig
vegas still crashing PM vega 64s at least. hopefully fixed soon
It is already fixed in 3.0b, which will be released tomorrow. Sorry about the delay.
WARNING! Because the new auto-tune functionality is automatically started if you don't specify -gt parameter, your hashrage will be lower and will fluctuate in the first few minutes while the miner searches for the best GT values for each GPU. If you want to avoid that, you have to specify -gt value on the command-line (or in config.txt). If you want the same behavior as 2.9e, specify -gt 15 (15 is the default value of the GT parameter).
How auto-tune works with -minRigSpeed option? I hope you ignore this option during auto tuning?
Good catch, with so many options is not possible to test all combinations. We have fixed this possible problem in 3.0b. Shouldn't be a problem for the initial auto-tuning because it usually finishes in less than five minutes but can definitely cause problems if the auto-tune is used later and -minrigspeed is specified.
6x 580 8g, from 175mh/s with 2.9 to 168 with 3.0 after 10 mins.
Going back to 2.9 for now
This shouldn't be happening. Possible reasons: different OC settings (clocks, voltages, sometimes the power limit can also be a problem even though the cards shouldn't be anywhere near it when mining eth). Another possible reason is a failure of the auto-tuning. Check with -gt 15 option instead (or whatever GT you were using with 2.9e) and you should have the same or slightly higher hashrate.
So I’m guessing that like most of the other neat features, auto-tuning doesn’t work for nvidia cards? The miner gives no feedback on My nvidia rig that auto tuning is doing anything. On my AMD rig it explicitly says in yellow text that auto-tuning is running.
also your readme file is not updated with any new information about the new features or usage.
Yes, the auto-tuning is only for AMD cards as it changes the GT parameter. We have tried to do something similar for Nvidia cards but they aren't affected by it. This is because the Nvidia cards are more balanced in terms of compute capability vs memory bandwidth and don't benefit from this kind of fine tuning. We are working on HW OC settings for Nvidia cards though, and it should be ready for the next version (3.1).
The new features and changes are moved in the ReleaseNotes.txt file because Readme.txt became too cluttered. Of course, the Readme.txt contains all current information about the command-line options.
In this version 3a, the antivirus finds a virus, this was not with any version before. Why is that?
Actually, almost all releases so far had problems with AV. As explained a lot of times, this is because the miner contains anti-debugger and anti-reversing code that is also often found in malicious programs. We tried largely unsuccessfully to work with AV vendors to white-list the program but it is just not worth the effort (and would slow our release cycles enormously). So, our advice is to use the provided checksums and check the integrity of the files, then add the folder where you keep PhoenixMiner to the list of exceptions in your AV software and forget about this.
Hello. After the launch of 3.0, my 1060 cards with Samsung memory began to show almost 27 mx each. Now the rig shows no 122.6 shows 131 mh. But the speed for 5 minutes 122,6 mx. Is it a mistake of the miner? I can not provide the screen, I do not know how .... Thanks.
This is a rare problem that can happen if the jobs are changing too often. In such cases the 5 min average is definitely the real number. To fix this pause the miner for 20-30 seconds and then resume it - the speeds should be back to normal after that.
