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

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

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

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

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:

   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

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

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

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

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.

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.

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.

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

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

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

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.

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

"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

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 

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

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

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!

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.

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

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.