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

[dohfish]

@PhoenixMiner - please research a bit the stale problem. With 2.5d i get 3, 4 even 5 times more stale vs. 2.4. Anyway, the miner is amazing, getting 6 mhs more from 192 to 198 mhs with 6 rx 580. Good job.
Also, please add to the miner cclock, mclock, cvddc, mvddc and other commands from Claymore, it would be really awesome.

can everyone please check effective hashrate on the pool side?

its relatively easy to have the excavator SAY you're running X MH/s, but if you aren't submitting shares consistent with that value, it doesnt matter and you will be paid based on a slower rate. this is what i experienced. I dont think anything nefarious is happening, and i like the communication from the dev thus far, but everyone should be diligent in tracking their ACTUAL performance vs what's reported.

in my case, over a 24hr period, Phoenix said it was running 2-3% faster, but submitted shares on nanopool were actually 2-3% lower than with claymore. I've switched back to claymore for now, but mainly ONLY because of the lack of tt and clock adjust functions. when those are added and the miner matures a bit, I'll give it a second shot.

24hours is way too little to make any measurements, you need 4-5 times that to get a good picture - From my experience phoenixminer, even the 2.5d is giving me more shares per day on ethermine compared to claymore, I actually have a machine with 12xRX580 which consistently underperforms with claymore miner, giving me fewer shares per hour than it should, on phoenix that machine runs smooth as butter.

V2.5d appears to have some stale share issues, it is actually leveling out a bit for me, but are still producing about 50% more stales compared to 2.4 - But 2.5d solves a problem which I have been having on one of my machines so overall there is improvement to track.

[1713956512]

1713956512

[1713956512]

1713956512

[gsrcrxsi314]

@PhoenixMiner - please research a bit the stale problem. With 2.5d i get 3, 4 even 5 times more stale vs. 2.4. Anyway, the miner is amazing, getting 6 mhs more from 192 to 198 mhs with 6 rx 580. Good job.
Also, please add to the miner cclock, mclock, cvddc, mvddc and other commands from Claymore, it would be really awesome.

can everyone please check effective hashrate on the pool side?

its relatively easy to have the excavator SAY you're running X MH/s, but if you aren't submitting shares consistent with that value, it doesnt matter and you will be paid based on a slower rate. this is what i experienced. I dont think anything nefarious is happening, and i like the communication from the dev thus far, but everyone should be diligent in tracking their ACTUAL performance vs what's reported.

in my case, over a 24hr period, Phoenix said it was running 2-3% faster, but submitted shares on nanopool were actually 2-3% lower than with claymore. I've switched back to claymore for now, but mainly ONLY because of the lack of tt and clock adjust functions. when those are added and the miner matures a bit, I'll give it a second shot.

24hours is way too little to make any measurements, you need 4-5 times that to get a good picture - From my experience phoenixminer, even the 2.5d is giving me more shares per day on ethermine compared to claymore, I actually have a machine with 12xRX580 which consistently underperforms with claymore miner, giving me fewer shares per hour than it should, on phoenix that machine runs smooth as butter.

V2.5d appears to have some stale share issues, it is actually leveling out a bit for me, but are still producing about 50% more stales compared to 2.4 - But 2.5d solves a problem which I have been having on one of my machines so overall there is improvement to track.

The DAG epoch changes in that time span.. it invalidates any comparison as whatever is run for round 2 will inherently be slower/less shares slightly that if it were run on round 1

[dohfish]

That is true, but giving that luck can factor for some 10% in some cases you really need more than 24 hours to give it a proper assesment.

[benosimo06]

Even with 2.5d now I'm unable to run the miner, though I'm starting to think it's something on my end. After further investigation once GPUs are identified in the console the error message: "FATAL ERROR: Debugger detected" is shown immediately before it crashes.

Any idea what might be the cause of this?

So I still have yet to find what is causing this. As per an early post in this thread with a similar issue with a Quadro GPU I understand that it's an anti-debugging feature kicking in, but I can't come up with a reason for it to do so.

Any suggestions? This miner was working amazingly for me prior to the ethermine issue and I'd love to get it running again!

[PhoenixMiner]

So I still have yet to find what is causing this. As per an early post in this thread with a similar issue with a Quadro GPU I understand that it's an anti-debugging feature kicking in, but I can't come up with a reason for it to do so.

Any suggestions? This miner was working amazingly for me prior to the ethermine issue and I'd love to get it running again!

   There was a change in the OpenCL initialization code in 2.5 (which will be made optional in 2.6) but if you are unable to run even 2.4 then something else has changed. Did you install any new software lately - new drivers, major Windows update, etc.?

I have been running PhoenixMiner 2.5d instead of Claymore for more than 24 hours and have to admit it is amazing.
My rig is 6x 1070 OC and I used to total 187 MH/s with Claymore: hashrate jumped 3.5% with same OC settings on Asus GPU Tweak II, so I was very pleased.
But the nicest part is that I was able to push OC even more with this miner, so GPUs are now running @ -91 core / +1592 mem smoothly, with avg hashrate of 196 MH/s.
Just by instaling this software and tweaking the GPUs, I gained more than 5% in hashrate, while paying less for dev fees.

ABOUT STALE SHARES: I have 28 after 24 hours, amounting to 1.36% on the total. Since I have no reference (first time mining with Phoenix), let me know if it's similar to what you are getting.
QUESTION: do you know if ethermine allows sending stale shares? I am not specifying the "-stales <n>" parameter, hence it's defaulting to 1 = "send stales"

So, I want to thank PhoenixMiner for the fantastic job and the great software.
Please keep squeezing performance from our almost-exhausted GPUs

    Ehtermine do accept stale shares as do most of the other pools. While they do not credit the shale shares at the same rate as normal shares, there is no downside in submitting stale shares if the pool accepts them. If the pool rejects all stale shares, you can stop sending them by using the -stales 0 (or -stales2 0 for the fail-over pool). You should check about your pool but as far as we know (and we can be wrong) from the big pools only nicehash doesn't accept stales.

    Another thing connected to stale shares is that we can't give 100% accurate assessment which shares are stale. The reasons are explained in our first post in this thread in the FAQ section:

Q003: What is a stale share?
   A: The ethash coins usually have very small average block time (15 seconds in most instances).
   On the other hand, to achieve high mining speed we must keep the GPUs busy so we can't switch
   the current job too often. If our rig finds a share just after the someone else has found a
   solution for the current block, our share is a stale share. Ideally, the stale shares should be
   minimal as same pools do not give any reward for stale shares, and even these that do reward
   stall shares, give only partial reward for these shares. If the share is submitted too long
   after the block has ended, the pool may even fully reject it.
 
Q004: Why is the percentage of stale shares reported by PhoenixMiner smaller than the one shown
   by the pool?
   A: PhonixMiner can only detect the stale shares that were discovered after it has received a
   new job (i.e. the "very stale") shares. There is additional latency in the pool itself, and in
   the network connection, which makes a share stall even if it was technically found before the
   end of the block from the miner's point of view. As pools only reports the shares as accepted
   or rejected, there is no way for the miner to determine the stale shares from the pool's
   point of view.

   The TLDR; version is that the estimated stale percentage shown by PhoenixMiner (or any other miner that reports stale shares) is at best equal, and in most cases lower than the final stales percentage, for which you should refer to the pool statistics. So why do we even bother to report it? Because high estimated stale percentages shown by PhoenixMiner indicate a latency problem in the rig itself and/or the miner options. For example the -mi (mining intensity) option can increase your hashrate but at the cost of higher latency, which leads to more stale shares. The default value of 10 works fine in most cases but if you like fine-tuning, play away, just know that there are trade-offs.

@PhoenixMiner - please research a bit the stale problem. With 2.5d i get 3, 4 even 5 times more stale vs. 2.4. Anyway, the miner is amazing, getting 6 mhs more from 192 to 198 mhs with 6 rx 580. Good job.
Also, please add to the miner cclock, mclock, cvddc, mvddc and other commands from Claymore, it would be really awesome.

24hours is way too little to make any measurements, you need 4-5 times that to get a good picture - From my experience phoenixminer, even the 2.5d is giving me more shares per day on ethermine compared to claymore, I actually have a machine with 12xRX580 which consistently underperforms with claymore miner, giving me fewer shares per hour than it should, on phoenix that machine runs smooth as butter.

V2.5d appears to have some stale share issues, it is actually leveling out a bit for me, but are still producing about 50% more stales compared to 2.4 - But 2.5d solves a problem which I have been having on one of my machines so overall there is improvement to track.

   While we can't see a significant change in the stale shares on our test rigs, one of the changes that we hastily made in 2.5d in an effort to prevent the ethermine connectivity problems could be causing this for some users. As we now know that that has nothing to do with the connectivity problems, we are rolling back these changes, so 2.6 should fix any unusual issues. The beta of 2.6 is already undergoing internal testing and will be released in less than 24 hours.

   The hardware control commands (cclock, mclock, cvddc, mvddc, etc.) are our next priority. Version 2.7 will contain some experimental support but we would need to test a lot on a matrix of GPUs and driver versions before releasing it. Please note that only AMD provides open access to its Overdrive API via the ADL library. While Nvidia has similar capabilities via the NVAPI, the hardware control and overclocking are only available if the developers are pre-approved by them. We will try to get access but it's probably not going to happen. So, at least for now the hardware control capabilities will be limited to AMD cards.

[uranus13]

I'm mining akroma at minerpool.net but phoenixminer report connection closed by pool, my batch file:

setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100

PhoenixMiner.exe -pool geo.pool.akroma.eu:8002 -wal $$$$.Rig001
pause

config file set default and nothing was change...

How can I change batch and config file for get better?? thanks 

[Khan3388]

"which probably means that you have to increase the size of your page file to at least 16 GB. Let us know if the increasing of the page file size (you have to restart Windows after that in order to apply the changes) doesn't solve the problem."

I had 25Gb pagefile size when i ran PhoenixMiners

[MokraCota]

I would switch to this miner, but it doesn't support Dual Mining (yet).
Really great job you have done here!

[Cemalefendi]

i hate  DAG recreation for devfee. please add another coin for devfee. like whale, victorium, mix , akroma etc.. if add i will use always. if not i cant use. many times have problem for dag creation. thank you for this good miner.

[dohfish]

@PhoenixMiner - please research a bit the stale problem. With 2.5d i get 3, 4 even 5 times more stale vs. 2.4. Anyway, the miner is amazing, getting 6 mhs more from 192 to 198 mhs with 6 rx 580. Good job.
Also, please add to the miner cclock, mclock, cvddc, mvddc and other commands from Claymore, it would be really awesome.

24hours is way too little to make any measurements, you need 4-5 times that to get a good picture - From my experience phoenixminer, even the 2.5d is giving me more shares per day on ethermine compared to claymore, I actually have a machine with 12xRX580 which consistently underperforms with claymore miner, giving me fewer shares per hour than it should, on phoenix that machine runs smooth as butter.

V2.5d appears to have some stale share issues, it is actually leveling out a bit for me, but are still producing about 50% more stales compared to 2.4 - But 2.5d solves a problem which I have been having on one of my machines so overall there is improvement to track.

   While we can't see a significant change in the stale shares on our test rigs, one of the changes that we hastily made in 2.5d in an effort to prevent the ethermine connectivity problems could be causing this for some users. As we now know that that has nothing to do with the connectivity problems, we are rolling back these changes, so 2.6 should fix any unusual issues. The beta of 2.6 is already undergoing internal testing and will be released in less than 24 hours.

   The hardware control commands (cclock, mclock, cvddc, mvddc, etc.) are our next priority. Version 2.7 will contain some experimental support but we would need to test a lot on a matrix of GPUs and driver versions before releasing it. Please note that only AMD provides open access to its Overdrive API via the ADL library. While Nvidia has similar capabilities via the NVAPI, the hardware control and overclocking are only available if the developers are pre-approved by them. We will try to get access but it's probably not going to happen. So, at least for now the hardware control capabilities will be limited to AMD cards.
[/quote]

Sounds good, my stale share calculations are based on the reported by the pool, not the reported by the miner which I know is not 100% - Will tinker a bit with -mi later today, but I just swapped the machine that produced most stale shares over the last 6 hours to 2.4 just to confirm that there's indeed "a problem".

[Branko]

i hate  DAG recreation for devfee. please add another coin for devfee. like whale, victorium, mix , akroma etc.. if add i will use always. if not i cant use. many times have problem for dag creation. thank you for this good miner.

man, I didn't have idea theres so many ethash coins, where you find them?

[Tsum]

Even with 2.5d now I'm unable to run the miner, though I'm starting to think it's something on my end. After further investigation once GPUs are identified in the console the error message: "FATAL ERROR: Debugger detected" is shown immediately before it crashes.

Any idea what might be the cause of this?

So I still have yet to find what is causing this. As per an early post in this thread with a similar issue with a Quadro GPU I understand that it's an anti-debugging feature kicking in, but I can't come up with a reason for it to do so.

Any suggestions? This miner was working amazingly for me prior to the ethermine issue and I'd love to get it running again!

I am getting the same issue and I do not know what it causing it either.

[pinoli]

this could be probably due to an antivirus program running on your OS.
Some AVs have "live protection" modes that scan for things like this and stop execution.

Please turn off or uninstall completely (the better way) your antivirus and try again
You could also try booting in safe mode (with networking) and see if it works.

[Tsum]

I don't have any anti-virus software. I turned off windows defender just to see if it would make a difference but I still got the same error.

[benosimo06]

I don't have any anti-virus software. I turned off windows defender just to see if it would make a difference but I still got the same error.

Hey I had the same idea and turned off defenders. No anti-virus on my rig either. Are you running Windows 10 as well? Is it a legit copy? Just trying to put the pieces together.

[janding]

try this
Start>>Run>>firewall.cpl>>Advanced>>Click "Settings" under ICMP

[Tsum]

I don't have any anti-virus software. I turned off windows defender just to see if it would make a difference but I still got the same error.

Hey I had the same idea and turned off defenders. No anti-virus on my rig either. Are you running Windows 10 as well? Is it a legit copy? Just trying to put the pieces together.

Yep, windows 10 and a legit copy. Tried the firewall.cpl thing without any luck either unfortunately.

[cidman]

still need to try this on other rigs but testing on a 390 and a 570
default intensity is giving a lil higher hash rate on the 390, thats noticeable
570 only a slight bump not so noticeable
im sure intensity will bring this up but...
the wattage drop compared to claymore is significant
this miner definitely seems like its using less resources overall to achieve the same purpose
gonna throw it on a 470 rig for a couple days

[PhoenixMiner]

New release candidate: PhoenixMiner 2.6b. It can be downloaded from here:
  (MEGA links are no longer active)

  Here are the checksums to verify the download:

Code:

    File: PhoenixMiner_2.6b.zip
   SHA-1: 83745294e4b8bd0ee9ab385b82ef7515885b8d2a
 SHA-256: 57b3f97da3918232205201daf548a522a1dba920c1fccd94a483bad30420ed59
 SHA-512: fb156c9ffa9fdfb042a7627386686a373bba9f9f951c924c30851f821dcfb3d62123c66a163677bc07b466d45e7fa5a3f2f2d8d4c770798afaafa4c3cfcb7d4b

   Note that this is not an official release yet but will probably become such in a few days. The changes are:

• Possible fix for the increase of stale shares that some are experiencing with ver 2.5d
• Made the new OpenCL initialization code optional (use -altinit option to use the new code if you experience crashes on startup)
• Added -lidag command-line option to allow slower but less intense DAG generation to prevent crashes on DAG switches (AMD only)
• Added a new interactive command in benchmark mode: press 'd' to advance to the next DAG epoch. You can use this option to test if your rig will be stable during the DAG swithes, instead of waiting up to 5 days to find out if this is the case.
• Turn off the Quick Edit functionality of the console to prevent freezing of the miner when clicking in its window (Windows 10)
• Show the IP address of the pool when connecting
• Show a '>' character in front of the pool address in the remote manager when trying to connect to a pool

[PhoenixMiner]

"which probably means that you have to increase the size of your page file to at least 16 GB. Let us know if the increasing of the page file size (you have to restart Windows after that in order to apply the changes) doesn't solve the problem."

I had 25Gb pagefile size when i ran PhoenixMiners

  Please try the new version 2.6b. It is possible that the new OpenCL initialization code introduced in 2.5d is not working well with your driver and if this is the case, 2.6b should solve the problem. Another possible way to fix the problem is to create a batch file to start the miner with the following contents (the important part are the setx statements to set the environment variables):

Code:

setx GPU_FORCE_64BIT_PTR 0
setx GPU_MAX_HEAP_SIZE 100
setx GPU_USE_SYNC_OBJECTS 1
setx GPU_MAX_ALLOC_PERCENT 100
setx GPU_SINGLE_ALLOC_PERCENT 100

PhoenixMiner.exe -clKernel 1 -pool eu1.ethermine.org:4444 -pool2 us1.ethermine.org:4444 -wal 0xd8081f58c43bd84f9a7882f613a9d8947fb31d00.farm1
pause

Even with 2.5d now I'm unable to run the miner, though I'm starting to think it's something on my end. After further investigation once GPUs are identified in the console the error message: "FATAL ERROR: Debugger detected" is shown immediately before it crashes.

Any idea what might be the cause of this?

  Can you please tell us what GPUs you are using and the version of the driver(s)?

Yep, windows 10 and a legit copy. Tried the firewall.cpl thing without any luck either unfortunately.

   Can you please tell us what GPUs you are using and the version of the driver(s)?