PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)

[Digital_Seytan]

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

[Stihlus]

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! 

[Marvell2]

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

[PhoenixMiner]

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

[laik2]

Hi,
Hawaii support is enabled in 4.2 version. Confirmed!

[Faizrakhmanov]

Hardware control options (-tt, -fanmin, -fanmax, -cclock, etc.) are not supported on Linux yet.

Is this -tmax 80 -tstop 85 -tstart 80 didn't work in Linux too? Thanks.

[Stihlus]

Thank you PhoenixMiner for your response.
Yes, it is strange because only 2-3 cards have this issue, go under 32.xxx and on both rigs is the same. If it's how you said then all should have the same speed ... this is the theory
I will try to update also the driver, maybe ... I will change something or I will destroy everything )

thanks and regards!

[lesjokolat]

Thank you PhoenixMiner for your response.
Yes, it is strange because only 2-3 cards have this issue, go under 32.xxx and on both rigs is the same. If it's how you said then all should have the same speed ... this is the theory
I will try to update also the driver, maybe ... I will change something or I will destroy everything )

thanks and regards!

I also recommend all cards are seated correctly in any associated risers. All cables firmly in place.

[Stihlus]

Thank you PhoenixMiner for your response.
Yes, it is strange because only 2-3 cards have this issue, go under 32.xxx and on both rigs is the same. If it's how you said then all should have the same speed ... this is the theory
I will try to update also the driver, maybe ... I will change something or I will destroy everything )

thanks and regards!

I also recommend all cards are seated correctly in any associated risers. All cables firmly in place.

I will check also the connections but it is strange because on 2 rigs I have the same issue. From 230 mhs to 225 (hashrate decrease on 3 cards).
Thanks for info!

[lesjokolat]

Green kernels do not work on vega 64 or radeon vii

Are they supposed to?

[Digital_Seytan]

PM developer thanks for the update 4.2.B but it often gets stuck at nicehash -> switch coin and of course with the DEVFEE .dit does not deliver much more Schares on the pole and a Rig miner starting every time is nothing but annoyance, system win10 / 64 pro last cuda version nvidia cards 1060/1070/1080.
is it sometimes the selection V2, also take a look at your colleagues devs with miner software such as TTMiner - BMiner and of course NBMiner Claymore we do not even talk about because that is far behind unfortunately.Leg soon a solution on your part please

[Digital_Seytan]

Why PhoenixMiner_4.1c_Windows with Nvidia cards running faster then PM 4.2.b  PM developer ??

Good day all

[Soliqesh]

-fcm fixed fans on my strix 588, thx so much

[Boogeymanrus]

Hello all.
Rig 5cards : 2 rx480 nitro+(ubermix 3.1) and 3 gtx 1070.
Driver 18.6.1 for rx
416.94 for gtx

Since 19/03 one of my rx480 nitro+ 11260-07-20G getting incorrect shares
What i tried:
Stock clocks and bios
Change risers, now it is in the main MB slot.
-clkernel 0/1/2/3
-clnew 0
-clgreen 0/1
-mi 6-14


And it still getting incorrect shares.
https://c.radikal.ru/c11/1903/fa/c1600b8d2485.jpg
Hwinfo says 0 errros

The second rx480 works fine no incorrect shares.
The miner 4.1c / 4.2a /4.2b doesnt matter.
I think this is new kernels, but don't know for 100%,.

Thanks

[PhoenixMiner]

The 4.2c is ready (this will probably be the final 4.2 release provided no major bugs are found). You can download PhoenixMiner 4.2c from here:

(MEGA links are no longer active)

If you want to check the integrity of the downloaded file, please use the following hashes:

Code:

   File: PhoenixMiner_4.2c_Windows.zip
    ===================================
   SHA-1: 6905a662d9d0ad790f2d13447252262ec66ea4d4
 SHA-256: b2ad6398594d4f92a55f8b03895bdc9be13d875ae9d373611b9ac4bd59554afc
 SHA-512: eaf6e810fa75fa977035f96d2d65902e99cb403b918ef50f2da44529302cabe15afe7c26e358fad3cf04be225d068457c717688de4bbcdf2ca6a3c531ea863e5

    File: PhoenixMiner_4.2c_Linux.tar.gz
    ====================================
   SHA-1: 487904d69dd671844dbaea3bd665adb2d38a7446
 SHA-256: b46c13db685c17884ebc73e23aedef3513d1d2bd0b52f20c0a2824e7bc90e9a0
 SHA-512: ae11c0998b2c96a0b380d539fddef9637a809212fbbf4c9cbfecfd820ec5f22f1b5544fdebf69f934b8b05523636e336b81014e00652aac287dc0a8ec2e91bf0

Here are the changes for this release:

• Added new Nvidia kernels v3 with slightly higher hashrate and lower power consumption. The new kernels are supported only on GTX1050/1060/1070/1080/Ti GPUs and are enabled by default on these GPUs. Note that you can't use these kernels for dual-mining, only -nvkernel 2 works for dual mining on Nvidia.
• Added parameter to enable or disable driver-specific optimizations on Nvidia GPUs. Use -nvdo 1 (the default is 0) to enable the optimizations. This won't change hashrate (or will change it only slightly) but may make the cards more stable depending on the concrete Nvidia driver.
• Fixed the slower DAG generation on Vega and Radeon VII GPUs
• Added support for Windows AMD drivers 19.3.3
• Small bugfixes

Here are the changes from 4.2a to 4.2b:

• Fixed the issue with Nvidia RTX20x0 and 1660 cards not working with 4.2a
• Fixed the problem with the watchdog timer when solo mining
• Added support for Windows AMD drivers 19.3.2
• Small bugfixes

Here are the changes from 4.1c to 4.2a:

• Added support for dual mining Ethash and Blake2s on Nvidia GPUs
• Added experimental support for ProgPOW mining of Bitcoin Interest (BCI). Note that the kernels are not optimized and only work on AMD. You must add -coin bci to the command line (or COIN: bci to your epools.txt file) in order to mine BCI.
• Added support for EthereumStratum/2.0.0 protocol (use -proto 5 if the pool requires it).
• AMD hardware control code was rewritten, now should be more stable and work on older cards too
• Added command-line option -fcm to set the way fans are controlled (AMD/Windows only). The possible values are 0 (auto; the default behavior), 1 (use VBIOS/driver), 2 (force custom control of the fans regardless of VBIOS/drivers fan curves, etc). Use -fcm 2 if the  fans are not controlled properly or at all
• Added support for Radeon VII
• Added support for AMD drivers up to 19.3.1
• Added new command-line option -nvkernel to select the old (v1) or new (v2) CUDA kernels. The possible values are 0 (auto; the default), 1 (use the old v1 CUDA kernels from PhoenixMiner 3.5), 2 (use the new v2 kernels, which were introduced with PhoenixMiner 4.0). This was added because there were some complains that the new kernels are running slower on some Nvidia cards. Note that v1 CUDA kernels doesn't support dual mining.
• Increased the maximum supported DAG epoch to 329. This should be fine for at least a year or so.
• Added support for direct mining without DAG switching of Yocoin (YOC), Bitcoiin2Gen (B2G), Ethersocial (ESN), Atheios (ATH), and REOSC. See the -coin parameter in Readme.txt for more information.
• Other small improvements and fixes.

Here is an example command-line for mining BCI (ProgPOW) - be sure to change YourBciWalletAddress with your actual BCI wallet address:

Code:

PhoenixMiner.exe -pool eu-1.pool.bci-server.com:3869 -wal YourBciWalletAddress.Rig1 -coin bci -proto 1

[PhoenixMiner]

Hardware control options (-tt, -fanmin, -fanmax, -cclock, etc.) are not supported on Linux yet.

Is this -tmax 80 -tstop 85 -tstart 80 didn't work in Linux too? Thanks.

   -tstart and -tstop will work as they only require the card temperature to be properly measured and this is supported in Linux. -tmax won't work in Linux.

Green kernels do not work on vega 64 or radeon vii

Are they supposed to?

   No, there are no green kernels (or turbo kernels) for Vega and Radeon VII.

Thank you PhoenixMiner for your response.
Yes, it is strange because only 2-3 cards have this issue, go under 32.xxx and on both rigs is the same. If it's how you said then all should have the same speed ... this is the theory
I will try to update also the driver, maybe ... I will change something or I will destroy everything )

thanks and regards!

   Try the new PhoenixMiner 4.2c - the new v3 kernels should decrease the power consumption and if the cards are hitting the power limit, this can increase the hashrate quite a bit. If this doesn't help, try -nvkernel 2 with and without -nvdo 1 to see if the hashrate stabilizes.

Hello all.
Rig 5cards : 2 rx480 nitro+(ubermix 3.1) and 3 gtx 1070.
Driver 18.6.1 for rx
416.94 for gtx

Since 19/03 one of my rx480 nitro+ 11260-07-20G getting incorrect shares
What i tried:
Stock clocks and bios
Change risers, now it is in the main MB slot.
-clkernel 0/1/2/3
-clnew 0
-clgreen 0/1
-mi 6-14


And it still getting incorrect shares.
Hwinfo says 0 errros

The second rx480 works fine no incorrect shares.
The miner 4.1c / 4.2a /4.2b doesnt matter.
I think this is new kernels, but don't know for 100%,.

Thanks

    This has nothing to do with the kernels as this is happening in only one card. The zero memory errors that you are seeing doesn't necessarily mean that the card is OK. Most probably the card itself is going bad (either the GPU or the VRAM, most probably the VRAM) as the percent of incorrect shares is very high. If the card has 8 GB VRAM, you can try a "workaround", which may work if only one of the memory chips is bad, so there is at least some region in VRAM, which is OK - when you see the incorrect shares, disable only this card from the PhoenixMiner, then run another instance of PhoenixMiner only on this card, which will create another DAG buffer, hopefully in a healthy region of the VRAM.

[WhyMe]

-clkernel 3 gives me 31.4MHs on RX 470 8Gb, 31.3MHs without. Is this normal ?

[zertor]

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.

Thanks, will do, but what bothers me is that in 1st post it says:

-lidag <n> Slow down DAG generation to avoid crashes when swiching DAG epochs
      (0-3, default: 0 - fastest, 3 - slowest). This option works only on AMD cards

this info is wrong/outdated?
will really works for Nvidia cards?

[sxemini]

-clkernel 3 gives me 31.4MHs on RX 470 8Gb, 31.3MHs without. Is this normal ?

you use 2 different kernels so the speed can be different. 

[fisnikshabani]

The 4.2c is ready (this will probably be the final 4.2 release provided no major bugs are found). You can download PhoenixMiner 4.2c from here:

https://mega.nz/#F!PBMmEKyK!glmhnZOuyfisObmnA9gGjA  (MEGA)

If you want to check the integrity of the downloaded file, please use the following hashes:

Code:

    File: PhoenixMiner_4.2c_Windows.zip
    ===================================
   SHA-1: 6905a662d9d0ad790f2d13447252262ec66ea4d4
 SHA-256: b2ad6398594d4f92a55f8b03895bdc9be13d875ae9d373611b9ac4bd59554afc
 SHA-512: eaf6e810fa75fa977035f96d2d65902e99cb403b918ef50f2da44529302cabe15afe7c26e358fad3cf04be225d068457c717688de4bbcdf2ca6a3c531ea863e5

    File: PhoenixMiner_4.2c_Linux.tar.gz
    ====================================
   SHA-1: 487904d69dd671844dbaea3bd665adb2d38a7446
 SHA-256: b46c13db685c17884ebc73e23aedef3513d1d2bd0b52f20c0a2824e7bc90e9a0
 SHA-512: ae11c0998b2c96a0b380d539fddef9637a809212fbbf4c9cbfecfd820ec5f22f1b5544fdebf69f934b8b05523636e336b81014e00652aac287dc0a8ec2e91bf0

Here are the changes for this release:

• Added new Nvidia kernels v3 with slightly higher hashrate and lower power consumption. The new kernels are supported only on GTX1050/1060/1070/1080/Ti GPUs and are enabled by default on these GPUs. Note that you can't use these kernels for dual-mining, only -nvkernel 2 works for dual mining on Nvidia.
• Added parameter to enable or disable driver-specific optimizations on Nvidia GPUs. Use -nvdo 1 (the default is 0) to enable the optimizations. This won't change hashrate (or will change it only slightly) but may make the cards more stable depending on the concrete Nvidia driver.
• Fixed the slower DAG generation on Vega and Radeon VII GPUs
• Added support for Windows AMD drivers 19.3.3
• Small bugfixes

Here are the changes from 4.2a to 4.2b:

• Fixed the issue with Nvidia RTX20x0 and 1660 cards not working with 4.2a
• Fixed the problem with the watchdog timer when solo mining
• Added support for Windows AMD drivers 19.3.2
• Small bugfixes

Here are the changes from 4.1c to 4.2a:

• Added support for dual mining Ethash and Blake2s on Nvidia GPUs
• Added experimental support for ProgPOW mining of Bitcoin Interest (BCI). Note that the kernels are not optimized and only work on AMD. You must add -coin bci to the command line (or COIN: bci to your epools.txt file) in order to mine BCI.
• Added support for EthereumStratum/2.0.0 protocol (use -proto 5 if the pool requires it).
• AMD hardware control code was rewritten, now should be more stable and work on older cards too
• Added command-line option -fcm to set the way fans are controlled (AMD/Windows only). The possible values are 0 (auto; the default behavior), 1 (use VBIOS/driver), 2 (force custom control of the fans regardless of VBIOS/drivers fan curves, etc). Use -fcm 2 if the  fans are not controlled properly or at all
• Added support for Radeon VII
• Added support for AMD drivers up to 19.3.1
• Added new command-line option -nvkernel to select the old (v1) or new (v2) CUDA kernels. The possible values are 0 (auto; the default), 1 (use the old v1 CUDA kernels from PhoenixMiner 3.5), 2 (use the new v2 kernels, which were introduced with PhoenixMiner 4.0). This was added because there were some complains that the new kernels are running slower on some Nvidia cards. Note that v1 CUDA kernels doesn't support dual mining.
• Increased the maximum supported DAG epoch to 329. This should be fine for at least a year or so.
• Added support for direct mining without DAG switching of Yocoin (YOC), Bitcoiin2Gen (B2G), Ethersocial (ESN), Atheios (ATH), and REOSC. See the -coin parameter in Readme.txt for more information.
• Other small improvements and fixes.

Here is an example command-line for mining BCI (ProgPOW) - be sure to change YourBciWalletAddress with your actual BCI wallet address:

Code:

PhoenixMiner.exe -pool eu-1.pool.bci-server.com:3869 -wal YourBciWalletAddress.Rig1 -coin bci -proto 1

Hi there,

Currently I work as a supporter for a group of clients who have rigs and as reward for the support, I take about 5% of total mined coins per 1 month. The payment (with coins) is done by the end of each month.
I was wondering is it possible to create an option for supportfee
It's OK to have a DevFee but also it could be useful for me to have a SupportFee.
For example I'll set 5% SupportFee which will be on my address and the rigs will mine 5% for me as a supporter.

Is it possible to have an option like this?

Thanks,