Quote from: PontusLSE on October 02, 2018, 06:27:40 AM

I am trying out this miner with good results so far.

I do however have one problem that I cannot seem to resolve. No matter how many pools I enter into epools.txt the miner ALWAYS reports that I have one more pool then I have actually entered. If I only have a single line in epools.txt the miner reports two pools when it starts, it tries to connect to the first one and fails because it simply does not exist ("could not resolve host"). After some time it tries the second pool (witch in fact is the first and only one) and it starts mining.

This example is working perfectly fine with claymore, but not with phoenix.

Code:

POOL: daggerhashimoto.eu.nicehash.com:3353, WALLET: , PSW: x, ESM: 3, ALLPOOLS: 1

I have the same problem on quite a few rigs. They are all running HiveOS (latest version).

Any suggested solutions?

Please note that the first one or two pools from the pool list may come from the command line. If you have specified one of the options -pool, -wal, -pass, -coin, or -proto on the command line (perhaps via the custom miner settings of the HiveOS control panel), this will specify a pool and since it is the first pool in the list, PhoenixMiner will first try to connect to it. You just need to remove all these options from the command line and then only the pools in epools.txt will matter.

Quote from: Aurren on October 02, 2018, 08:28:30 AM

Code:

...

As you can see, it takes about 40 seconds to initialize the first 3 cards, the log is pretty much the same through the rest of the DAG creation. It was able to get a valid share while the DAG was being created for the other cards so it's working as soon as the card is finished initializing.

on -gser 1 it would just list the first 3 cards:

GPU1 GPU1: Starting up... (0)
GPU2 GPU2: Starting up... (0)
GPU3 GPU3: Starting up... (0)

but it would never show "GPU1 Eth: Generating light cache for epoch #214" for any cards after that.

Thank you for the log! Apparently, the light cache generation is not causing the problem but perhaps some incompatibility of the Linux kernels with some Nvidia cards (the light cache is created only once by whatever GPU starts first and then is used by all the other GPUs). We have included same measures in the development version of 3.6 to detect better what happens right after the light cache generation, and we will update the CUDA kernels for Linux, so hopefully this will solve the problem in the next version.

Quote from: agismaniax on October 02, 2018, 02:54:42 PM

I always use custom fan curve setting in MSI Afterburner or Sapphire Trixx. I set the fan speed to 5 points above the GPU's temperature. For example, if the GPU's temp is 52C, then the fan will spin at speed of 57%, 65C temp 70% fan, and it always spin based on current GPU's temp. Can this custom fan curve setting be done via PhoenixMiner?

No, with PhoenixMiner you can either fix the temperature (e.g. -tt 60) or the fan speed (with negative number after -tt). You can also set a maximum fan speed but that's it. We will update the hardware control options in Mil Shield 3.6 but such custom fan curves are beyond what we have at mind for now.

Quote from: j2james on October 04, 2018, 11:45:40 AM

Hi PM developers.

Today I have updated PM from 3.0c to 3.5d. And I cannot connect to CDM remote monitoring. I did not change -cdmport and -cdmpass.

I use command line parameters (not config file): -cdm 2 -cdmport 3333 -cdmpass xxxxx

Any ideas?

I have checked with config file. The same problem.

After back to 3.0c all works (with command line parameters and with config file)

The only change with respect to remote monitoring in 3.5d is that now it starts 10-20 seconds after the miner starts but otherwise it should be working fine - we are using it 24/7 on our test rigs without any problems. From our own experience, this problem is perhaps related to Windows Firewall, which blocks the CDM port for the executable of the new version (it should show you a pop-up window, asking if you want to open the port the first time you start the a new version of PhoenixMiner). Another possible reason (again related to Windows Firewall) is that it may "decide" that the local network is "public" instead of "private" and it has much more strict rules for public networks, so it again blocks the CDM port of PhoenixMiner. A quick test to see if the Firewall is the culprit is to turn it off for a short time and see if the remote management works.

Quote from: lemonyo30 on October 05, 2018, 11:45:30 AM

I need Help please, im getting this error below, changed as well 5555 still the same error

Code:

No CUDA driver found
Available GPUs for mining:
GPU1: Radeon RX 580 Series (pcie 2), OpenCL 2.0, 8 GB VRAM, 36 CUs
GPU2: Radeon RX 580 Series (pcie 3), OpenCL 2.0, 8 GB VRAM, 36 CUs
Listening for CDM remote manager at port 3333 in full mode
Eth: the pool list contains 4 pools
Eth: primary pool: eu1.ethermine.org:4444
Starting GPU mining
Eth: Connecting to ethash pool eu1.ethermine.org:4444 (proto: QtMiner)
GPU1: 24C 70%, GPU2: 21C 70%
Eth: Could not connect to ethash pool eu1.ethermine.org:4444: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
Eth: Reconnecting in 20 seconds...

There are two possible reasons for this: you either have connection problems - check your network settings, DNS settings, etc., or you have left YourWallet as the wallet name in the command-line settings (the .bat file), or in the epools.txt file - in such case replace YourWallet with your actual wallet address.