Any plans on Zilliqa support for "dual" mine?
Can you work on adding pow for ziliqua to this miner ? It uses the same ethhash algo, all you would have to do is copy the parts from the source of zilminer where it stops mining main coin , and then starts zil pow 2 min or so befoe the ziliqua pow so it has time to load dag etc, should be very easy to do
We can't promise anything at this point as there are too many feature requests waiting to be implemented and with the looming ProgPOW change most of this work may be quite short-lived anyway.
phoenixminer b series getwork style eth_submithashrate not work, other c or a series getwork style submithashrate is fine working. but c or a series not stability on getwork mode. pls fix submithashrate for b series
Thank you for reporting this! It will be fixed in PhoenixMiner 4.2c, which will be released in a few days.
this thing is crashing periodically by identical way,
without any error messages
and unable to self reset either.
its just self quit.
happens on 1080 Ti cards
(tried drastically down-clock them, nothing helps, swap is set to min 65555MB)
As this seems like a problem with DAG generation, please try using
-lidag 1 (or more) to lower the DAG generation speed.
same as on my side - dont understand why not only one card crashed...instead all cards HS0 instant and nothing helps but reset
We will make same changes in Nvidia kernels in PhoenixMiner 4.2c that will hopefully increase the stability. Unfortunately, when the driver crashes, it is not always graceful and it can crash the miner without returning error codes or giving us a chance to restart the miner. The fact that only restart fixes the problem definitely points to a driver crash.
Automatic fan control ( -tt value) does not seem to work for one my cards (r9 290) does anyone know how to resolve this ?
Hi friend. Same problem too on my RX578 and RX588.
PS. HiveOS (last ver + 4.2a miner).
Hardware control options (-tt, -fanmin, -fanmax, -cclock, etc.) are not supported on Linux yet.
Just tried 4.2a BETA and can confirm -fcm 2 does make a difference, I see the fans respond to temperature will test more.
One odd thing I observed is that this version applies OC differently, it applied voltage to all GPU core states - is this normal ? The thing is that I didn't ask it to do that, I dont have anything regarding voltage in command line as I use OverdriveNTool for OC and now the miner overrides OverdriveNTool's settings. Is there any way to disable this behavior?
Thanks.
Please check your command line - it must not include -cclock, -cvddc, -mclock, -mvddc if you want PhoenixMiner to leave the core clocks and voltages alone. Even if you have only -
cclock, the miner will set the voltage to the lowest possible value for this clock from the VBIOS performance levels, so either set both -cclock and -cvddc on PhoenixMiner's command-line, or set both the clocks and voltages via OverdriveNTool.
Last version on 15-GPU nvidia rig show unreal share accepted times (50-70-2000-3500ms), version 4.1 shows right 39-44ms share acctepted time, just FYI
We have tested with multi-GPU rig on pool with very low difficulty, and we didn't see difference between 4.1 and 4.2. Please check if you are connecting to the same pool (including the location of the pool - if it is close to you or not), also if you are connecting to a low-difficulty pool, which causes the rig to submit many shares per minute. Many pools will delay the share confirmations if you are submitting a lot of shares because there is no downside for the miner and the pool can lower the resource usage.
Phoenix Miner 4.2b Windows/msvc - Release build Problems please help
-----------------------------------------------
CUDA version: 10.0, CUDA runtime: 8.0
Available GPUs for mining:
GPU1: P106-100 (pcie 1), CUDA cap. 6.1, 5.9 GB VRAM, 10 CUs
Nvidia driver version: 419.35
NVAPI error in NvapiWrapper.c:204 : -6
Unable to load NvAPI: error 3
Eth: Loading pools from epools.txt
Eth: the pool list contains 1 pool (1 from command-line)
Eth: primary pool: daggerhashimoto.eu.nicehash.com:3353
Starting GPU mining
GPU1: unable to init NvAPI with bus ID 65536 !!!!!!!!!!!!!
PM developer please help maby next version..
Thank you for reporting this. It will be fixed in PhoenixMiner 4.2c
Hello guys!
I have one issue and I don't know where to start. Couple of weeks before(2-3 weeks before) everything was fine .
I have 2 rigs x 7 cards, 1070, win 10, driver 398.36 and Phoenix Miner 4.0b and the speed was 230-231 for each rig, it was perfect since I changed with that DAG from 2.9e version.
All cards was around 32.7-8 and now both are with 225-226 total and I don't understand why...2-3 cards are under 32...
I have:
power: 60%
clock: -150
memory: 780
Maybe if I will update the drivers I will solve the issue? But this is strange because if it is like this all the cards will be the same.
On both rigs to have the same issue, this is why I don't understand, the same speed... if there was an issue with the setup, maybe it was different :\
thanks and regards!
Unfortunately, there is a gradual hashrate drop for the GTX1070 cards with the increase of the DAG size (we are seeing it from about DAG 200). To be sure that this is the problem, run PhoenixMiner in benchmark mode. To do this, add
-bench 100 (this will simulate mining with smaller DAG for epoch 100) to the command line, leave the miner working for several minutes to stabilize the hashrate and write it down. After that repeat the test with
-bench 250 and after running several minutes, note the difference in speed. In our testing we've seen drop from 174 MH/s at DAG 200 to 168 MH/s at DAG 246 with GTX1070. Maybe this can be solved by a driver update from Nvidia but nothing is certain. Interestingly 1070Ti doesn't seem affected (or at least the slowdown is much slower).
