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

PhoenixMiner 2.8c: it is better

https://www.virustotal.com/#/file/6ba0037119a36c700be613faba03deb0e2342039e1938b8d802fcd5f70433ef0/detection

PhoenixMiner 2.8c: fastest Ethereum/Ethash miner works Great thanks.

in my case dont forget for Nvidia cards (-mi 10) with this code on the bat file.

Please add more auto functions

No. It will not work with NVIDIA cards.

PhoenixMiner 2.8c doesn't report Hashrate when I'm mining with HTTP GetWork through local eth-proxy.exe
I tried to set -rate 1 param but no effect.

Here is my cmd-line:
PhoenixMiner.exe -amd -coin eth -gwtime 50 -rate 1 -pool http://192.168.10.12:8090/rig1

In help file of 2.8c -tstop and -start are placed inside section "for AMD cards only". I hope it is by mistake? Will it work on NVIDIA cards or no?

I used to do that. There are things that only windows task manager can do and that is why I use it, by the way thanks.

You should place link to bat file in autostart menu. Bat file you can place to folder where phoenix miner is placed and set for link to this but file current directory to directory where this bat file is placed.

  No, the speeds are shown every 5 seconds or so. If there is enough requests for such feature, we can add it.

  You can use the -clnew 0 to revert to the old kernels. If you want to use the old kernels on specific GPUs only, use -clnew 1,1,0,1,1 for example to use the old kernels on the third GPU on a five GPU rig. Note that there are some changes in the new kernels in 2.8c, which may solve the problem with the hashrate drop after found share. Also note that -clnew is only available in 2.8c (not in 2.8b).

   -eres 0 was always going to be just a temporary solution. The real solution is to switch to Windows 7, which reserves less than 5% of the GPU memory unlike Windows 10. This is a long-standing problem with Windows 10 and despite the numerous requests from users, it is unlikely that Microsoft will resolve it. Note that some miners report success with Windows Server but we haven't tested this personally.

   We print the GPU which finds the share in the log and in the console like this (in this instance GPU1 has found the share):

   The new kernels should be more stable as this was one of our design goals. You can use -mi 10 to get the same intensity as before, or revert back to old kernels with -clnew 0

   Have you turned on Compute mode on all cards? It is on card-by-card basis, unfortunately there is no way to turn on the compute mode for all cards at once, so you have to do it one by one. The difficulty has nothing to do with your hashrate, so this is not the reason for the slower speed.

   Check the overclock settings on GPU2 as it seems that the problems start from there.

Sample .bat file for those new to egem. 

PhoenixMiner 2.8c is officially released. Note that there are changes since 2.8b, so if you are running 2.8b, you should upgrade to this version. Here is the full list of changes since 2.7c (the last official release):

• New kernels for all supported AMD GPUs, providing higher hashrate and lower percentage of stale shares. The new kernels are used by default for AMD GPUs. You can also revert to using the old kernels with -clnew 0
• When using the new kernels, the mining intensity is 12 by default instead of 10
• The mining intensity range is now up to 14. Use high -mi only with the new AMD kernels as for the other kernels the stale shares will increase too much
• Small CUDA kernel stability improvements that also may (very) slightly increase the speed of Nvidia cards
• CPU utilization during normal operation is lowered by about a factor of 10 regardless of the number of GPUs
• Added support for -tstop and -tstart options to stop mining on given GPU if the temperature rise above specified value and restart it after it cools down below -tstart temperature
• Fixed the problem with console window freezing after scrolling
• Implemented new -gpow n option to lower the GPU utilization (default: 100, the value is the desired GPU utilization in percent)
• Implemented the -li option to lower the intensity (use this instead of -gpow if you are already using -mi with low values)
• Improved GPU speed statistics, using moving average window for each GPU. You can change the size of the window with the -gswin option (5-30 seconds; default 15; use 0 to revert to the old way of using 5 second "quants" which are independent of each other)
• Specify GPU number above 9 by typing three-digit sequence at the console (e.g. type 011 to pause or resume GPU11)
• Other small improvements and changes
• Added support for the miner_getstat2 remote monitoring request

We are now working on 2.9, which will include new CUDA kernels for Nvidia GPUs and other improvements.

I found my problem, it seems that calling the bat file using the windows task scheduler with or without the highest privileges means both ways think is using the highest privileges even though is not. Strange. I have to find a way to turn this thing off.

Does anyone know if we can via config define a set difficulty hashrate?

I tried both ways, with and without highest privilege rights and nothing changed. I know, it's odd.

Edit: There is no hope at all, tried all possible things, all user groups and everything possible concerning privilege and the only way it creates a log is when I click on  the bat file.

One last guess from me.
Any chance that when it auto starts from the scheduler that it doesn't have Admin privileges ?

Yes, if I manually click, it creates the log, if is automatic by the windows scheduler then no. If it was a path problem then clicking manually would not help either. It is terrible cause if a gpu crashes and it auto restarts then you have no idea which gpu crashed. I searched the whole drive cause I thought it may have been written to another directory, for example temp in appdata and no, it could not be found at all. 2.7c also had problems related to this. So what is wrong with this miner? Claymore eth miner never had this kind of problem.

That is odd.
Could it be a path problem ? Doesn't know where to write them.

the 2.8b is not creating logs when you put it on the schedule tasks on windows to start automatically, it creates the log only when you click on it manually. Strange behavior.

I agree.
I mine on Ethermine which shows stats on stale shares.
Testing both Phoenix and Claymore on the same pool proves Claymore is much better.
Phoenix doesn't seem to be concerned with solving the stale share issue.
They are living in denial. Claymore seems to have solved that issue, consistently giving me
around 1 to 2% stale shares while Phoenix is 4 to 8% and sometimes higher. The little extra speed
that Phoenix gives me doesn't make up for the 2x to 4x higher stales.
I had high hopes for Phoenix, but it isn't working out.

I think cetain pools have worse latncy. Im on suprnova and my stales are very low(.25%) daily avg. over the last few days. Claymore i was getting a solid 1.5 to 2.5% stale using a lower mining intensity. Hash rates were also on avg 1 to .5 mh/s.

all i can recommend have a clean system, fresh installed use latest drivers both mobo and watman or nvidia. I honestly think it will solve alot of these more cryptic code erros and issues people see.

glta

It pains me to say it but while the numbers phoenix reports, and its lower fee... I actually do get better numbers with claymore..   

I find myself disappointed. because on paper phoenix was streaks ahead, but the numbers at the pool were a good chunk below reported and stales were much higher..