Quote from: benosimo06 on January 31, 2018, 03:59:26 AM

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

Quote from: pinoli on January 30, 2018, 04:57:27 PM

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

Quote

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.

Quote from: DeDeRa on January 30, 2018, 06:41:49 PM

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

Quote from: dohfish on January 30, 2018, 10:27:11 PM

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.