Quote from: MoNTE48 on April 15, 2018, 01:29:13 PM

Hi. What about Linux version?

Coming in the near future.

Quote from: syraka76 on April 15, 2018, 03:28:31 PM

seems ok, but I encountered a problem, I use the remote manager of claymore, and works on everything, but with version 2.9e and only sees the AMD, the gtx says that they are not connected, instead turn quietly, you happen?

Undecided

Check if the port you are using for remote monitoring is free - you can't have more than one program on the same rig using the same port for remote management.

Quote from: Digital_Seytan on April 15, 2018, 10:38:16 PM

What are we still happy with phoenixminer 2.9.e the stale shares are back again, while it was with the 2.9 .d away the joy is so short-lived unfortunately.

There are no changes that affect stale shares at 2.9e, so it must be bad luck (or pool issues). The internal stale shares in 2.9 are close to zero (less than 0.1% to be exact) and practically all stale shares are because of a) latency of your connection to the pool, and b) latency of the pool itself.

Quote from: khafan11 on April 16, 2018, 08:46:43 AM

i'm back to 2.8C , i had better hashrate with that ! RX580 8Gb MSI Gameing X

You may need to try -clkernel 2 and/or different -gt values to achieve optimal hashrate with the new kernels. Otherwise, you can go back to using the old kernels with -clnew 0.

Quote from: Sandro6666 on April 16, 2018, 08:53:59 AM

Unfortunately still crashes after CUDA errors with Nvidia gtx 1070 cards. The last one that restart well after CUDa errors is 2.7c for me.

It would be very helpful if you could send as a log file of one of the crashes that doesn't restart the miner. 2.9e should catch all types of error and exceptions in the GPU threads and reboot instead of crashing. Perhaps one of the other threads has crashed but we can't know for sure without a log (just the last few pages before the crash).

Quote from: j2james on April 16, 2018, 10:08:05 AM

Hi developers, is it possible to provide information about power usage? By rig and by a separate card. Or at least bu rig?

Theoretically, the GPUs report some kind of power usage but we have observed that it is very far from the actual numbers (even when taking into account the efficiency of the PSUs). So, while we can report them, they are at best grossly incorrect, and at worst - misleading.

Quote from: Battousai1 on April 16, 2018, 11:12:52 AM

Hi guys, I would like to know, if you run two or more instances of Phoenix Miner, will the mining speed of those instances be reduced compared to running only on one instance? I am planning on running at least two instances of Phoenix Miner.

Lastly, when running another instance of Phoenix Miner, what is the best practice, should I just create another batch file in the same folder or create a new folder with a another executable file of Phoenix Miner? I am currently using two batch files with one executable file in a single folder and it is working fine.

Thank you in advance for any replies.

There shouldn't be any noticeable performance decrease from running few instances but the memory usage will be higher and the chance for stale shares may be elevated slightly due to all instances receiving new job(s) at about the same time. It is best to copy the program at two different folders (if nothing else, at least you will be able to clearly separate the log files this way) and use different config.txt and epools.txt files. You can place the options in the config.txt and the pools in epools.txt. Then the bat files will contain just:

Code:

PhoenixMiner.exe
pause

Quote from: j2james on April 16, 2018, 11:25:22 AM

Looks like 2.9e on 6 GTX-1070 is less profitable then 2.8c.

My params are the following

-nvidia -cdm 2 -cdmport 3333 -cdmpass -minRigSpeed 188 -rmode 2 -tstop 65 -tstart 40

PM 2.8c gives me 191.65MH and costs 750W (1MH costs 3.913W)
PM 2.9e gives me 192.5MH and costs 760W (1MH costs 3.948W)

It is not critical, of course, but...

Good news: PM 2.9e provides more stable hashrate then PM 2.8c or any Claymore or any Ethminer.
I have 0 stale shares during 1:25 (1 hour, 25 minutes).

The deceased stale shares alone should be more than enough to offset the power difference. You can still use -nvnew 0 to revert to the old CUDA kernels but this will increase stale shares significantly.

Quote from: sidaliroy on April 16, 2018, 04:29:29 PM

Tested 2.9e for one day and here's my results:

x6 RX 580 4GB Sapphire (Stable 188mh/s - same hashrate as 2.8c)
x6 RX 570 4GB Armor (Very unstable 185mh/s - lower hashrate than 2.8c and it was more stable compared to 2.9e)
x6 RX 570 8GB Sapphire (Stable 193mh/s - lower hashrate than 2.8c)

Experiencing high stale shares on my RX 570 Armor Rig which wasn't the case in version 2.8c

Hopefully next update will be better.

The lower hashrates are probably because you have to use different -gt values with the new kernles (or try -clkernel 2). The higher stale shares are definitely caused by something outside the miner, as in 2.9 the internal stale shares are practically eliminated.

Quote from: rendysatrya on April 17, 2018, 04:14:12 AM

My phoenixminer 2.9e always freeze when the miner trying to connect ethermine for dev fee mining. Anyone else experiencing the same?

What coin you are mining? Most probably the miner can't determine it automatically and then it defaults to ETH for devfee. If you GPU(s) don't have enough memory for ETH DAG, the miner can crash. To avoid this, use the -coin command-line option to specify the coin that you are mining and PhoenixMiner will use it for devfee, avoiding the expensive DAG regeneration.

Quote from: kdminhkhanh on April 17, 2018, 10:43:07 AM

Help Me!

I have a 1060 6gb card running with 2.8c then it's normal. MSI: Pow 65 core -400 mem 700. But when using 2.9e with MSI as above it error:

Code:

2018.04.17:03:23:55.234: GPU5 CUDA error in CudaProgram.cu:264 : an illegal instruction was encountered (715)
2018.04.17:03:23:55.243: GPU5 GPU5 search error: an illegal instruction was encountered
2018.04.17:03:23:55.254: GPU6 CUDA error in CudaProgram.cu:124 : an illegal instruction was encountered (715)
2018.04.17:03:23:55.254: GPU6 GPU6: Failed to initialize search buffers: an illegal instruction was encountered
2018.04.17:03:23:55.254: GPU6 GPU6 initMiner error: Unable to initialize CUDA miner
2018.04.17:03:23:55.271: GPU4 CUDART error in CudaProgram.cu:127 : an illegal instruction was encountered (73)
2018.04.17:03:23:55.271: GPU3 CUDART error in CudaProgram.cu:127 : an illegal instruction was encountered (73)
2018.04.17:03:23:55.271: GPU3 GPU3 initMiner error: an illegal instruction was encountered
2018.04.17:03:23:55.271: GPU4 GPU4 initMiner error: an illegal instruction was encountered
2018.04.17:03:23:55.271: GPU1 CUDART error in CudaProgram.cu:127 : an illegal instruction was encountered (73)
2018.04.17:03:23:55.271: GPU1 GPU1 initMiner error: an illegal instruction was encountered
2018.04.17:03:23:55.272: GPU2 CUDART error in CudaProgram.cu:127 : an illegal instruction was encountered (73)
2018.04.17:03:23:55.272: GPU2 GPU2 initMiner error: an illegal instruction was encountered
2018.04.17:03:23:55.518: wdog Thread(s) not responding. Restarting.

https://imgur.com/a/ViuWr

Please help me adjust the MSI so that I get the highest productivity on the 2.9e. Thanks very much!

You may need to decrease the memory overclock. The new CUDA kernels are utilizing the GPU more fully, which may lead to such problems when the overclocks are on the edge of stability. Another possible remedy is to try and force the cards to be in P0 performance state instead of P2, which by some accounts makes them more stable at high overclocks.