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

I think the only way how to survive new Claymore version is to implement into Phoenix algos for dual mining, which Claymore DOES NOT HAVE! Then I would love to use Phoenix on all my rigs.

For you, and anyone else loosing hashrate for this - Simply disable polling of the watts used by the GPU, this is the culprit - Polling anything else but hiding the watts used by core etc will not cause a drop in hash power.

Isn't there a way to automate this? Have the miner calculate a moving average while it's changing this parameter, thus finding out the best for each card.

"PhoenixMiner, the miner taylored to your cards" does sound appealing.

Great Work on the miner. Over all I think your miner is better than Claymore's.

I've been testing this on two rigs for the last 24hrs. One 9 card Zotac 1070 AMP Extreme rig, and one 9 card Zotac 1070 ti AMP Edition rig . I use NVIDIA Inspector 1.9.7.8 to set OC's using a .bat and short cut of .bat in Windows start folder.

I found your miner allows my 1070 AMP Extremes to take a higher and more standard Mem Over Clock across all cards. With Claymore every card had a different Mem OC but with Phoenix miner all but one 1070 likes a standard 850 Mem OC. But for what ever reason there was no change with the 1070 ti rig, it still likes the same OC as Claymore's miner.

The only thing I don't understand is why GPU0 is GPU1. This makes the fan speed and temp readout in the miner not line up with the correct cards.

Fan temp on GPU0 = GPU5 in Phoenix             Hashrate of GPU0 = GPU1 in Phoenix
Fan temp on GPU1 = GPU1 in Phoenix             Hashrate of GPU1 = GPU2 in Phoenix
Fan temp on GPU2 = GPU2 in Phoenix             Hashrate of GPU2 = GPU3 in Phoenix
Fan temp on GPU3 = GPU3 in Phoenix             Hashrate of GPU3 = GPU4 in Phoenix
Fan temp on GPU4 = GPU4 in Phoenix             Hashrate of GPU4 = GPU5 in Phoenix
Fan temp on GPU5 = GPU6 in Phoenix             Hashrate of GPU5 = GPU6 in Phoenix
Fan temp on GPU6 = GPU7 in Phoenix             Hashrate of GPU6 = GPU7 in Phoenix
Fan temp on GPU7 = GPU8 in Phoenix             Hashrate of GPU7 = GPU8 in Phoenix
Fan temp on GPU8 = GPU9 in Phoenix             Hashrate of GPU8 = GPU9 in Phoenix


I read though all 25 pages and didn't see anyone else mention this.

   Yes, you can do this and it is quite easy. The first step is to have two copies of the PhoenixMiner folder. Then add the command line option -gpus 123456 to the command line of the first miner (or in the config.txt file if you are using config.txt file instead of directly adding command-line options). This will limit the first instance of PhoenixMiner to the first six cards of your rig. For the second instance of the miner use the option -gpus 7,8,9,10,11,12 and it will use the other six cards.
   If you want to use remote monitoring, you have to add the option -cdmport 3334 on one of the instances (first or second) because they cant both run on the default port 3333 for remote monitoring.
   As for the more probability of getting shares, we don't think that it would make much difference but you can use one half of the rig to mine on one pool and other - on different pool and compare which works best for your. Or you can even mine different coins.

   We will release an early beta tomorrow or the day after tomorrow (depending on how the internal testing goes). The "seemless" devfee switch is already undergoing testing and works quite stable but the hardware control options are nowhere near completion, so we will probably release a 2.7a versions without them but with all the other new features first.

   There is quite small difference unless you go to really high gt values (above 30-40). Also, give it at least 30-60 seconds for the hashrate to "settle" after changing the gt value before moving to the next gt value (you can move by 10, for example from 15 to 25, then wait one minute to see what the hashrate looks like when it stabilizes, then repeat and so on).

   Yes, this is normal, and the same effect can be observed with GPU-Z when looking in the sensor tab. The reason is that the ADL library is not thread-safe and the sensor readings can't be read in parallel, which slows down the driver, especially when all available sensors are read every second or so, which is the normal mode of operation of these programs. If you want to keep them in the background, make sure that the frequency of reading of the sensors is not too high (for example once every 10-30 seconds should be fine but once every few seconds is too often).

   Could give us some specifics? How menu cards you have, and what command line you are using? Note that the -gpus option GPU indexes start from 1, not 0 like in the -di option. So, if you want to use only the first three cards, you have to use -gpus 123 or -di 012.

   Hmm, this is something new. So far we have seen this only with AMD cards. Would you mind telling us what program you are using for setting the clocks and voltages of your cards?

Nvidia here, all 1060s.

Good to know, thanks! I am Nvidia only so with the recent AM update I will start to use this with Awesome Miner ASAP.

Hi all!
8 * 580. eth only.
claymore was 227 mh/s and ~ 200 shares / hour
phoenix are 228 -229 mh/s and ~ 204-207 shares / hour
base on logs - really low dev fee
thank author for new interesting product!

I have both Nvidia and AMD and this problem occurs on AMD rig only.. Strange is also, that it resets only some of cards.
Mostly it resets PCIe 16x primary slot..Then random resets. Sometimes third card...sometimes second card.

This needs to be fixed definitely..

The -gpus command does not work. I cannot mine with only specific gpus. Any suggestions?

Does it reset the OC settings on bothe AMD and Nvidia or just AMD?

Miner works great here minus the bug where it resets my OC settings at every devfee, will wait til its fixed and go back to use it.

Thank you.

if you use awesome miner and don't know yet this now works with awesome miner .....

Run -gpus 123456 on one instance (or other indexes of your preference/need) and -gpus 7,8,9,10,11,12 on another instance.
Still, I agree with ANewMiner, I do not believe it will increase profitability or share increase.

Keep in mind that PhoenixMiner shows which actual difficulty it took to find the share, greater difficulty equals greater payment from the pool. So bigger number of shares does not mean more profit.

Though honestly, that is one test I haven't even thought to try myself. Please report back your findings


It does, in my case the difference is very slight for each change, also, the change take some time to kickin, it takes patience to tune the gpu's this way.


I thought it was me, with your comment plus the previous answer from Phoenix team, it makes sense to me that reading the gpu directly take some processor's time, HWiNFO does this while running the sensors. What I did was to tweak the interface to not only hide the items I want to see (mostly Memoty Errors) but also uncheck "monitoring".
Hope that helps

aurus

My result with Phoenix miner on one RX560  (Hynix) and one RX580 (Elpida)

my 1060-3 cards recently stopped mining 179 epoch ether classic. Only ethminer is working longer on this coin. I solved all dev recommendations below, but had no success.

Using the -gt tuning can make a worthwhile increase in your hash rates.
This is only used for AMD cards.

Here is how I found the best way to tune and use it.

Have your miner up and running.
Using the '+' key increase the tuning parameter to a larger number than you need.
Start out at 100.
Watch your displayed hash rate in the mining window.
Let it display a few updates to see where the speed is currently running.
Decrease the tuning number by 10 using the '-' key.
Watch the hash rate.
Continue decreasing the number by 10 on each test while watching the hash rates.
You should see the hash rate starting to increase as you go down in numbers.
The hash rate will increase and then start to decrease.
When you reach that point you are close.
Now start going up and down by 5 instead of 10 on each test.
You will eventually find the sweet spot where you can't improve it any more.
Set that number in the -gt parameter in your config.txt file.

If you have multiple GPU's in a system you will need to do this for each GPU.
Disable all the GPU's but one. Find the best number for that GPU.
Record that number then disable that GPU and enable the next one.
Repeat until you have all the setting for each GPU.

This can take some time, but it’s worth it.

Hi again,

I would like to understand further the lines of text printed on the console while the miner application is running.
Could you help me understand:

1. How to find out which GPUs are idle (waiting for job) and which GPUs are busy solving an algorithm?
2. How to find out how long it took to finish a share? and are shares solved by 1 GPU only or which GPUs helped to complete the share?
3. How to find out when a solution was submitted?
4. What is difference between "New job found... from " and "ETH share found"?

Let me know if these are details found on console of the app, or such debug strings can be printed by adding a parameter to the script, or such details are unavailable or do not exist.

Reason for asking this is that we could be too caught up with hashrates (processing power) and yet forget that idle GPUs (due to absence of a job or difficulty finding a share) affect performance too. No point overclocking GPUs only to be stuck waiting like a Ferrari stuck in traffic.

Thank you in advance.

Thank you for your reply. I also have no idea if it would so I had to ask just in case you would happen to know if it does improve getting shares.

My max hashrates are better with your miner than with Claymore's but I noticed that my effective hashrates are not so consistent, thus bringing down my average hashrates. I've been using your miner for just a day and noticed this. Not sure if it's related to that bug of GPU changing voltages during devfee mining. I didn't notice that but I saw someone post about it a few posts earlier.

http://

I'm permanently running HWinfo to detect potential memory errors. I have not experienced any hashrate loss.
HW ifo is hidden in the tray.