Hi.
There is no way to. make afterburner work after 3 gpu with new amd adrenalin driver. I tried ddu and i installed from lower version of 18.xxxx to higher but no luck. it works with 1 or 2 rx570 when you installed 3rd card it doesn't allow me to OC my gpu cards.Rx 570 cards are there but all cards are Gray out. so you cannot change anything there. Anybody has got idea or advice? Many thanks in advance.
We don't know why is this happening but it probably has nothing to do with PhoenixMiner. You can try using the built-in hardware overclocking options in PhoenixMiner, they should work fine with the latest drivers.
The new version improve the hashrate for rx580 8gb. But for my Rx 470/570 4gb is better Kernel 2 and more low than claymore
We will provide new alternative kernel for Polaris (the one that is activated with -clkernel 2 in the current version) in the final release of 2.8.
2.8b is very good!
One wish in comparing with Claymore:
1. Claymore have intensity from 0 to 16. 8 is default. If I use GPU for other purposes during mining (video, small games) Claymore miner just lower the speed and other 3D app runs good.
2. Phoenix miner have intensity from 0 to 14. 12 is default. Speed a bit higher than Claymore with default intensity in PM (12) and in CM (8 ). But Phoenix miner during mining and playing even weak games drops speed of mining even more than Claymore but gives less power to D3D app.
Lowering intensity to 9 in PM lower the speed but nearly not increase D3D power for apps.
Can you add in miner auto detection of D3D usage by other app and auto lower intensity for it? I just use my 1st GPU not only for mining...
Sorry if it too hard but Claymore can do that... I hope that you also can do that!
And another one question:
What about GPU tuning parameter in new kernels? Does it the same as in 2.7 or maybe 15 is not optimal now?
You can specify different mining intensity for the first GPU and the rest by using
-mi 0,12,12,12 for example if you have 4 GPUs and the display is connected to the first of them. Our range of mining intensity is in fact wider as it is logarithmic instead of linear, so there is no direct equivalence. You can try -mi 0, which should provide virtually no lowering of the speed of your 3D games but of course the hash-rate will be lower. The idea of detecting 3D load is interesting but we can't promise when (or even if) it will be implemented. We have some other potential solutions for this kind of mixed type usage but they will have to wait for the future versions.
The GPU tuning parameter should be about the same.
Hey PM, thanks for the update, Quick question: The text "You can also revert to using the old kernels with -clkernel 1" it sounds to me like a typo, on the readme.txt file, it states that 0: generic, 1: optimized, 2: alternative
But in your update you're saying that with option 1 you're reverting back to old kernels, so, which one to use for 580's? 0 or 1 option?
Thanks
Yes, sorry, this wasn't clear enough. If you want to use the new kernels, don't specify any -clkernel option - the new kernels are turned on by default on the supported GPUs. If you want to mix the kernel types on the same rig, you can use -clkernel 3 for the new kernels and -clkernel 1 or 2 for the old kernels. In the final 2.8 we will provide new version of the -clkernel 2 kernels too, and the old kernels will be retired for good as the options are becoming too complex without any benefit for the end user.
About 0.5-0.75% stale shares still there.
Yes, we don't aim for 0% stale shares as this isn't helpful for the overall hashrate, and this is all that matters in the end. We aim to extract the best effective hashrate, including the stale shares.
switched my AMD rig from 2.7c to 2.8b
6x rx570 4gb
2x rx580 4gb
2.7c - 228.3MH
2.8b - 229.8MH
0.65% speed increase. power consumption is the same about 1090W from the wall. good stuff.
PM: is it worth it to move an nvidia rig from 2.7c to 2.8b? i'm guessing no?
It is, as there were small changes in CUDA kernels in 2.8a (which are also included in 2.8b), which may slightly increase your hashrate (and certainly won't decrease it). We are preparing new CUDA kernels as well but they will be ready for 2.9 and will provide another small speed increase.
Phoenix do wrong calculate of stale shares percentage.
Total shares - 200. Stales - 2. Est. stale percentage - 1.10%.
But 2/200*100 = 1.0%
Does PM pessimist?
Note that we take the share difficulty in consideration when calculating the stale share percentage - so this is probably not wrong but either your pool changes the difficulty of the shares and the stale shares happened to be with higher difficulty than the average difficulty of the accepted shares, or the pools have switched and the stale shares are from the pool with the higher difficulty. For example if you have 200 shares with average difficulty 3150MH and 2 stale shares with average difficulty 4000MH, the stale shares percentage is shown as 1.1% even though 2/200 = 1%. This is the best way to do it as it won't invalidate your stats if you switch from a pool with difficulty 4000MH to a pool with difficulty 10000MH.
@PhoenixMiner
I guess congratulations are in order for successfully duping the general population
that are trying to use your miner that the fake number you display in the miner is
actually the real stale share rate.
I actually thought you were honest. You've let them believe it without continuing
to specify that that is not a honest representation of stale shares.
Luckily for you most people don't mine in a pool that shows them the actual stale shares.
I can't use your miner any longer. I know that number is false and now I don't think
I can trust you.
I know I'll catch crap from people who think I'm wrong, but you know I'm not.
5x to 10x more stale share from your miner than Claymore. ( AT THE POOL )
The first post of this thread (as well the Readme.txt that is shipped with the miner) state clearly that the stale shares shown by PhoenixMiner are always less than or at most equal to the stale shares of the pool. The was repeatedly explained during the course of this thread (you can search back if you want). The reason why this "internal" stale share percentage is important and will be shown by PhoenixMiner was also stated a few times - it allows you to see what you are losing if you increase the mining intensity too much.
The other stale shares that are result of pool's latency (and not only in your connection to the pool but also the delay in the pool notification that there is a new job) are completely outside the miner's control and can't be affected by any of your settings. Furthermore, we can't know when the pool actually has switched the jobs, so there is no way to show the number of these shares with the information that the miner has.
Finally, as already explained, we try to optimize the overall effective hashrate, including the stale shares, instead of just minimizing the stale shares.
Hi Phoenix,
FYI the readme.txt that comes with 2.8b still says the -mi paramaters is up to 12, with 10 being default i.e. the old values.
Thanks for catching this, it will be fixed in the new Readme.txt.
@Phoenixminer
Good job with the 2.8b, its running pretty good.
Question, can we use a proxy with your miner ?
If yes, which one do you recommend ?
Thank you
Yes, you can. If it uses the HTTP getwork protocol, you will need to add the http:// prefix in front of the proxy address like this:
-pool http://192.168.0.45. Frankly, we don't know which proxy to recommend.
