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

for nvidia card Phoenix miner can provide very similar to claymore.
But for AMD cards definetely slower than claymore.

I use same settings for 6pcs RX470 cards.
Claymore gives 29.8 mh/s for each card, phoenix gives around 28 mh/s and it is not stable.

I running PM 3.0a 24h on my rig. For now i havent problems for now. Hasrate is same like 2.9e version, little better are accepted shares.

Actually, after restart, values are back to 31.

Hello.
I can see big HR improvements on some of my 1070. From 31 to 35 which is great.

Prior to 3.0, value after "Eth speed:" in console was submitted to pools as reported hashrate.
Now as "Eth speed:" I have 241, but on ethermine reported HR is 223 (same as "Average speed(5 min)" on console).
Is that intentional?

Thanks.

Hello dear miners, After waiting so long for a new version of Phoenixminer I had actually expected more novelties and more functions than just -gt what does not work correctly.raar actually had at least expected that at startup we would at least get rid of those numbers but even that is a lot expected I personally think of the dev.success people with the new version of phoenixminer ....


----------------------------------------------------------------------------


WiNEther Miner is a graphical interface to use with ethminer with advanced watchdog options and monitoring................. . .. Download : https://github.com/digitalpara/WiNETH

Hello,

Silly question, do you have problems with windows 10 1803 and nvidia cards?
After some research on the internet, of course ... there are different opinions :/
On one rig I still have 1709 and it's ok but with 1803 it's a big problem, at least for me. No way to use the same settings as on windows 1709 (like 60% tdp, -100 core and +780-800 memory) now I have restart after restart (15-20 min and baang...restart) even with +750 memory. I don't know what's different...I've done a fresh install but it's the same, today I will install again but definitely 1709 and trying to postpone how much I can the 1803 update.

Have a nice day and regards

   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).

  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.


   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.

    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.


  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! 

   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.

   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.

  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

   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.

   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.


   OC doesn't affect rejected shares, only incorrect shares. If you have (a lot of) incorrect shares or the miner crashes, then lower OC.


   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.


   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.

   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.

   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.

   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.


   It is already fixed in 3.0b, which will be released tomorrow. Sorry about the delay.


   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.


   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.


   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.


   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.

  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.

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.

In this version 3a, the antivirus finds a virus, this was not with any version before. Why is that?

Doesnt seem to work on nvidia cards

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.

Great post.
All that information and logs you included will definitely be helpful for the devs to see what might have happened.
Next time don't hog the page with so much stuff.

6x 580 8g, from 175mh/s with 2.9 to 168 with 3.0 after 10 mins.

Going back to 2.9 for now