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

If you want to mine CLO, no worker after the wallet. wallet.worker don´t work, but only wallet without worker works perfect.

Hi all, have rig with x6 RX580 8GB(x3 XFX GTS and x3 STRIX TOP Gaming), when i start miner with parameter -tt 64, miner set only for 3 cards XFX (Claymore work fine for all gpu). Help pls( Screen: https://i.imgur.com/LPRmrWq.png

In my case, because callisto is not supported yet, I had to set another coin for the dev fee due to having a graphic card with low memory (dag size). I chose pgc because I assumed that it was going to have a smaller dag than ETH (the default one).
If you are mining etc by all means set it at etc so it doesnt have to download the dag from a different coin and it will use the same one you loaded when you started the miner.

Why -coin pgc ? It should rather be: -coin etc 

Mining with 2.9e since the release and having 157mh/s reports by the miner and the pool so far, no crashes no nothing! Great work man!

Tested. It still not work with 1063 on win10, Sad.

Hi first time i try to switch from claymore for mining CLO (Callisto) (Ethash algorythm) and impossible to connected to the pool apparently...

Here's my logs :

2018.04.18:22:54:36.527: main Phoenix Miner 2.9e Windows/msvc - Release
2018.04.18:22:54:36.527: main Cmd line:
2018.04.18:22:54:36.527: main config.txt: -pool clo.2miners.com:3030 -wal 0x4C79A838Eb620E22218A77a2bDc5651b549ea77e.RX480
2018.04.18:22:54:36.527: main No CUDA driver found
2018.04.18:22:54:38.593: main Available GPUs for mining:
2018.04.18:22:54:38.593: main GPU1: Radeon (TM) RX 480 Graphics (pcie 1), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU2: Radeon (TM) RX 480 Graphics (pcie 3), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU3: Radeon (TM) RX 480 Graphics (pcie 4), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU4: Radeon (TM) RX 480 Graphics (pcie 5), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU5: Radeon (TM) RX 480 Graphics (pcie 6), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.593: main GPU6: Radeon (TM) RX 480 Graphics (pcie 7), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.04.18:22:54:38.681: main ADL library initialized
2018.04.18:22:54:39.035: main Listening for CDM remote manager at port 3333 in read-only mode
2018.04.18:22:54:39.035: main Eth: the pool list contains 2 pools
2018.04.18:22:54:39.035: main Eth: primary pool: clo.2miners.com:3030
2018.04.18:22:54:39.035: main Starting GPU mining
2018.04.18:22:54:39.035: main Matched GPU1 to ADL adapter index 64 (method 1)
2018.04.18:22:54:39.262: main GPU1: Created ADL monitor for adapter 64; overdrive version: 7
2018.04.18:22:54:39.262: main GPU1: using AMD driver ver 18.3.4
2018.04.18:22:54:39.262: main Matched GPU2 to ADL adapter index 16 (method 1)
2018.04.18:22:54:39.431: main GPU2: Created ADL monitor for adapter 16; overdrive version: 7
2018.04.18:22:54:39.431: main GPU2: using AMD driver ver 18.3.4
2018.04.18:22:54:39.431: main Matched GPU3 to ADL adapter index 32 (method 1)
2018.04.18:22:54:39.528: main GPU3: Created ADL monitor for adapter 32; overdrive version: 7
2018.04.18:22:54:39.528: main GPU3: using AMD driver ver 18.3.4
2018.04.18:22:54:39.529: main Matched GPU4 to ADL adapter index 48 (method 1)
2018.04.18:22:54:39.615: main GPU4: Created ADL monitor for adapter 48; overdrive version: 7
2018.04.18:22:54:39.615: main GPU4: using AMD driver ver 18.3.4
2018.04.18:22:54:39.615: main Matched GPU5 to ADL adapter index 80 (method 1)
2018.04.18:22:54:39.692: main GPU5: Created ADL monitor for adapter 80; overdrive version: 7
2018.04.18:22:54:39.692: main GPU5: using AMD driver ver 18.3.4
2018.04.18:22:54:39.692: main Matched GPU6 to ADL adapter index 0 (method 1)
2018.04.18:22:54:39.785: main GPU6: Created ADL monitor for adapter 0; overdrive version: 7
2018.04.18:22:54:39.785: main GPU6: using AMD driver ver 18.3.4
2018.04.18:22:54:39.786: wdog Starting watchdog thread
2018.04.18:22:54:39.786: main Eth: Connecting to ethash pool clo.2miners.com:3030 (proto: EthProxy)
2018.04.18:22:54:39.872: eths Eth: Connected to ethash pool clo.2miners.com:3030 (95.213.255.168)
2018.04.18:22:54:39.872: eths Eth: Send: {"id":1,"jsonrpc":"2.0","method":"eth_submitLogin","worker":"eth1.0","params":["0x4C79A838Eb620E22218A77a2bDc5651b549ea77e.RX480"]}

2018.04.18:22:54:39.940: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":null,"error":{"code":-1,"message":"Invalid login"}}
2018.04.18:22:54:39.940: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

2018.04.18:22:54:39.940: eths Eth: Connection closed by the pool
2018.04.18:22:54:39.940: eths Eth: Reconnecting in 20 seconds...
2018.04.18:22:54:39.987: main GPU1: 31C 66%, GPU2: 32C 66%, GPU3: 40C 73%, GPU4: 30C 66%, GPU5: 34C 66%, GPU6: 32C 66%


And this is my BAT start file :

setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100

PhoenixMiner.exe -pool clo.2miners.com:3030 -wal 0x4C79A838Eb620E22218A77a2bDc5651b549ea77e.RX480 -pass x -coin etc

Any help would be appreciated

Thanks.

 

what is your bat file for phoenix miner? standard commands wont work.thx in advance

@PheonixMiner

Still having issue with 2.9e with Nvidia 1070 not rebooting with reboot .bat when miner crashes



2018.04.18:12:26:33.440: gps0 CUDA error in CudaProgram.cu:168 : unknown error (999)
2018.04.18:12:26:33.440: GPU1 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.446: GPU1 GPU1 search error: unknown error
2018.04.18:12:26:33.462: GPU8 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.462: GPU8 GPU8 search error: unknown error
2018.04.18:12:26:33.462: GPU7 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.462: GPU7 GPU7 search error: unknown error
2018.04.18:12:26:33.468: GPU9 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.468: GPU9 GPU9 search error: unknown error
2018.04.18:12:26:33.482: GPU3 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.482: GPU3 GPU3 search error: unknown error
2018.04.18:12:26:33.482: GPU6 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.482: GPU6 GPU6 search error: unknown error
2018.04.18:12:26:33.494: GPU5 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.494: GPU5 GPU5 search error: unknown error
2018.04.18:12:26:33.495: GPU2 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.495: GPU2 GPU2 search error: unknown error
2018.04.18:12:26:33.535: GPU4 CUDA error in CudaProgram.cu:264 : unknown error (999)
2018.04.18:12:26:33.535: GPU4 GPU4 search error: unknown error
2018.04.18:12:26:34.158: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}

2018.04.18:12:26:34.204: wdog Thread(s) not responding. Restarting.
2018.04.18:12:26:34.296: eths Eth: Received: {"jsonrpc":"2.0","id":0,"result":["0x8cc4101785c8e5f40e72a0abf5651c3711a3cafd57475f8ba5c2059146633adc","0x5683748fa7f53897f1e1a80a8a321d3693761838135be37d1d132c0cd3d7d937","0x000000006df37f675ef6eadf5ab9a2072d44268d97df837e6748956e5c6c2116"]}

I am not sure! Why dont you just give it a try!

I didn't have a problem with other older miners in win 10 provided the 1060 3gb was not the main graphic card with a monitor connected. With a monitor the graphic memory usage goes too high.

1063 problem is dag file for ETH on windows10. Claymore fixed this problem  for few next epochs. So my question: is it possible to mine eth on 2.9e with 1063 on windows 10 or no?

Sorry I can't understand you well. If you mean if it works with a nvidia 1060 3gb, the answer is yes! Although not sure it can do ethereum anymore, but still good for other ethash coins.
In the bat file you are going to have to add the command:
-coin pgc

I use that one to mine Callisto and it doesn't matter that it is not the same coin I am mining.

This is because by default, the dev fee mines ethereum, which might use too much memory and crash the miner.

This is my bat:
setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100
PhoenixMiner.exe -pool YOURPOOL -wal YOURADDRESS -coin pgc -gpow 95 -lidag 1

The 2 last commands are to reduce gpu use so I can use windows at the same time and to make the miner more stable when it loads the dag file.

Does 2,9e work with 1063 or still no?

Hey if any of you re interested check out

ETH.ethertrench.com

FREE mining pool. No pool fees.  Low latency(few stales). If I compare my overall returns for the same hashrate as I had when I was on Supernova the payouts are almost double!!!

Pays out very quickly no hassles, also pays for valid uncle shares(stales) as well.

its a smaller pool so finds less often but has large miners come and go that help frequency of finds.

i ve used Phoenix on here for the last few weeks and its been great.

FYI disclosure. I have no affiliation to anyone running or on the pool.

Enjoy!

https://preview.ibb.co/nxOgbn/Capture.png

Getting good results from 2.9e. thank you dev team

Thanks again Phoenix

updated from 2.8 to 2.9e and went from about 418.9 to 421.3(at the pool)      stales dropped from 2-3% down to 1% (at the pool )

keep up the good work

Apologies again. Not my intention, I am just weird.

I am sincere in this... I will take your advice!

it is unbelievable, from the 2.8 to 2.9.e is amazing difference with the same start bat 0 stale shares on the screen some stale shares on the pool screen but still much and much less, so go through phoenix developer.

can you share a screen shot of your RIG pool results? would love to see this 0% stale shares

   Coming in the near future.


   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.


   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.


   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.


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


   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.


   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:


  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.


  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.


  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.


   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.