Could you also try to fix problem with AMD cards? All of them are not detected by PhoenixMiner in HiveOS based on Ubuntu 18.04:
No OpenCL platforms found
No avaiable GPUs for mining. Please check your drivers and/or hardware.
This build is named "Bleeding edge" =)
https://hiveos.farm/install One of the problems we found with the latest HiveOS can be fixed by removing the LD_PRELOAD environment variable. To do so, please insert the HiveOS USB flash drive with the already setup as a custom miner and started at least once PhoenixMiner 3.5d on a PC and open the following folder in Windows explorer:
/hive/custom/phoenixminer/. There you will find a file named
h-run.sh. Open it with Notepad and add the following line
unset LD_PRELOAD immediately before above the command that starts PhoenixMiner:
unset LD_PRELOAD
./PhoenixMiner$@
If you are Linux-savvy, you can do this while HiveOS is running fron an SSH session and edit the file directly with the nano text editor.
It seems the latest version (3.5d) has problem with '-coin' param. I have specified '-coin clo' (or any coin) but at first it shows "Mining CLO on..." and later it shows "Mining VIC on..."
VIC is dev's favorite coin?
It just a coincidence that currently VIC and CLO are on the same DAG epoch. Note that the
-coin parameter works only for the pools specified on the command-line (with the
-pool and
-pool2 command line parameters). If you have specified failover pools in the epools.txt file, you have to specify the coin for each pool in the list with
, COIN: clo appended in the end of the pool line. If the coin isn't explicitly specified for one of the pools, PhoenixMiner tries to guess it from the DAG epoch but when two or more coins are currently in the same DAG epoch, it may guess wrong.
However, this won't have any negative effect because when the DAG epochs are the same, there will be no DAG generation before or after the devfee periods anyway.
At the same time, on different machines, the miner hangs on generating a light cache for the epoch. ver.3.5d
.....
We are investigating similar issue on Linux, but this is the first report that we get for similar behavior on Windows. We will try to reproduce it here and fix it.
On HiveOS as well, was getting the same problem, and then I tried -gser 2, and that was able to initialize the first 5 cards until the miner detected that my other 3 cards (all NVIDIA 1060 3gb) was unresponsive and it restarted the miner again, then it just keeps going in that loop of creating the DAG for 5 cards and restarting the miner. Is there a way to delay the miner from checking the cards until the -gser 2 has a chance to create the DAG for all the cards?
EDIT: I also want to add that the current HiveOS startup for claymore can load the DAG for all 8 cards all at once.
Please try using the
-gser 1 option, or turn off the watchdog with
-wdog 0 and see if this fixes the problem. We will make changes in the next release but it is important to know what is happening to avoid the problem in the future.
Hello PhoenixMiner!
Can you please tell me when it is planned to launch a dual mining (if planned)? If so, which algorithms are considered first? If you can, wish, then I would like to Blake2s
In advance I thank for answers!
About 90% probability that in the next version (3.6), there will be support for Blake2s.
we might have a winner here, switched over a bunch of rigs unstable undr claymore and the run greaat under your new kernal. The powersavings is legit too 1 to 2% per rig
also got better stability and constant hash rate on my furys too!!
this is your best release phoniex team , i have 300 amd card im switching over as we speak
any cance you can create a progpow miner , i suspect eth will be switching ovee some time next year
ProgPOW is certainly in our plans, and we will definitely add support one way or the other. Even if ETH drags its feet, we expect ETC or some other ethash-based coin to step up and support the network decentralization and security by adopting ProgPOW.
