not OC just basic run and it breaks after the 5th share here is the error again and again, installed 390 driver
CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
GPU3 search error: unspecified launch failure
CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
GPU4 search error: unspecified launch failure
CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
GPU6 search error: unspecified launch failure
CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
GPU2 search error: unspecified launch failure
CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
GPU1 search error: unspecified launch failure
CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
GPU5 search error: unspecified launch failure
CUDART error in CudaProgram.cu:422 : unspecified launch failure (4)
GPU7 search error: unspecified launch failure
Thread(s) not responding. Restarting.
using command line :
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 -nvidia -pool us1.ethermine.org:4444 -pool2 eu1.ethermine.org:4444 -wal mywallet.rig -proto 3 -eres 0 -lidag 2
still not working, can anyone help on this?
Unfortunately, we can't reproduce it here. Does it happen with older versions too and what kind of cards you are using? This error happens when the program is trying to run the search kernel after the DAG was already successfully created, so it is even more puzzling.
An issue with 2.6;
A machine that works as expected with 2.5d, with 2.6 after it creates the DAG file and starts mining the main thread is somehow reported as not responding although it is still mining. I've setup the reboot.bat file so the machine goes into reboot loop after that.
....
Thanks for reporting this issue and for the log - it is obvious that the main thread is not dead but the watchdog decided that it is, so we'll see what could be causing this. The restricted net access is not to blame for this as even if you stop the Internet access entirely no thread should freeze.
I try PhoenixMiner 2.6b with recommended above parameters, on Farm1 PhoenixMiner didn't start and show the same error "clCreateCommandQueue (-6)" but on second Farm PhoenixMiner started up and started working. After restart PhoenixMiner on Farm2 I recive error "clCreateCommandQueue (-6)" again
I try restart PhoenixMiner and MSI Afterburner several times and change parameter GPU_FORCE_64BIT_PTR from 0 to 1 and backward - i have achieved success several times (PhoenixMiner
started UP sometimes)..
What i noticed, when Phoenix starts up normally Phoenix define 4GB VRAM, when Phoenix can't starts, it define only 3GB VRAM
Log when Phoenix can't start:
17568:15:09:59.153: main No CUDA driver found
17568:15:09:59.477: main Available GPUs for mining:
17568:15:09:59.477: main GPU1: Radeon RX 570 Series (pcie 1), OpenCL 1.2,
3 GB VRAM, 32 CUs
17568:15:09:59.477: main GPU2: Radeon RX 570 Series (pcie 2), OpenCL 1.2, 3 GB VRAM, 32 CUs
17568:15:09:59.477: main GPU3: Radeon RX 570 Series (pcie 4), OpenCL 1.2, 3 GB VRAM, 32 CUs
17568:15:09:59.477: main GPU4: Radeon RX 570 Series (pcie 5), OpenCL 1.2, 3 GB VRAM, 32 CUs
17568:15:09:59.477: main GPU5: Radeon RX 570 Series (pcie 6), OpenCL 1.2, 3 GB VRAM, 32 CUs
17568:15:09:59.491: main ADL library initialized
Log when Phoenix started normally:
17569:20:12:50.903: main No CUDA driver found
17569:20:12:51.179: main Available GPUs for mining:
17569:20:12:51.179: main GPU1: Radeon RX 570 Series (pcie 1), OpenCL 1.2,
4 GB VRAM, 32 CUs
17569:20:12:51.179: main GPU2: Radeon RX 570 Series (pcie 2), OpenCL 1.2, 4 GB VRAM, 32 CUs
17569:20:12:51.179: main GPU3: Radeon RX 570 Series (pcie 4), OpenCL 1.2, 4 GB VRAM, 32 CUs
17569:20:12:51.179: main GPU4: Radeon RX 570 Series (pcie 5), OpenCL 1.2, 4 GB VRAM, 32 CUs
17569:20:12:51.179: main GPU5: Radeon RX 570 Series (pcie 6), OpenCL 1.2, 4 GB VRAM, 32 CUs
17569:20:12:51.192: main ADL library initialized
My rigs have 2GB RAM Memory (900-800 MB free when all works)
Sorry for my english)
Something is wrong with your drivers. We've never seen RX 570 to report less than 4 GB of memory or only OpenCL 1.2 (it reports OpenCL 2.0). You probably have to use DDU to remove your drivers then install them again (for example the blockchain drivers) and make sure that they are patched if you have BIOS modded your cards.
I really hope the stale shares issue recoding works. I'm getting 2x or higher more state shares than Claymore.
It's quite obvious to see in the charts from ethermine.org.
While it will have positive effect, most of these stale shares (if you are using 2.6) are mostly random and depend on the current pool server (some are busier than the others and the latency is worse). We haven't seen anything close to 2x than Claymore over a long period of time.
After download, the antivirus show file has virus
anybody help me?
It's a false positive, you can safely ignore it (but if your PhoenixMiner.exe file suddenly got deleted by your AV, make sure that it is white-listed). If you want to be sure that the files wasn't tampered with, you can use the hashes in the first post of this theme to check if the downloaded files are the same as the ones we've uploaded.
i have not read the all post, i want to know is possible to use voltage, overclock, underclock directly from the bat file like i used to do with claymore?
Not yet, we are working on this.
I'm testing this miner about a week on few rigs, but have mixed feelings. Ammount of info in console = great. Readability of these info = very bad (I wrote about it few days ago). Reported hashrate about 1-2 Mh/s higher than Claymore. But. This is just a teoretical number and what matters are accepted shares. And with Phoenix I have less accepted shares last days then in Claymore.
Sometimes it has weird behavior - autostarting miner after reboot gives me sometimes very high accept share time, about twice as high as normal. Quitting miner and starting it again solve this sometimes.
On rig started restarting itself, after running few minutes of Phoenix. (NVidia GPUs)
Tried a lot of testing, -mi settings, but I still don't have a feeling, it is the best miner. Time will show... Keep up good work, idea is nice. Thanks
Please check the IP addresses of the pool servers you are connecting with after the reconnect. Some of them are really overloaded and the latency may become very large. We will include stats about the pool latency in the future. When you reconnect to the same pool URL, the load balancing servers often connect you to a different server with new IP address that may be less loaded and hence the different latencies.