Topic: PhoenixMiner 6.2c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux) - page 347. (Read 784857 times)

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,

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

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

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

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

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



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


   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.



    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.

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:

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:

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

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

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

Good day all

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

Green kernels do not work on vega 64 or radeon vii

Are they supposed to?

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!

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

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!

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

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

   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.


   Thank you for reporting this! It will be fixed in PhoenixMiner 4.2c, which will be released in a few days.


    As this seems like a problem with DAG generation, please try using -lidag 1 (or more) to lower the DAG generation speed.


   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.


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


    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.


    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.


    Thank you for reporting this. It will be fixed in PhoenixMiner 4.2c



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

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

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! 

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