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

   2.8b will be released late Sunday or early Monday depending on stability during the internal tests.

   The way we have implemented the devfee switching in PhoenixMiner, there is no disruption in the GPU workload, nor any downtime at all. The switchover is absolutely transparent for the GPU and there is no lost hashrate.

Rapidly switching between the 2 mining modes ("mine for yourself" and "mine for developers") puts rapidly changing workloads and heavy stress on GPU. It noticeably shortens the GPU's life and causes problems and weird breakdowns.

Also the switching causes a considerable loss of connection time, when it's not mining for anyone (neither for yourself nor for the developer). This lost time can even be longer than the time devoted to developer mining. The more frequent the switching is, the higher the loss. 90 minute period is quite frequent, do this 16 times a day and it easily wipes out any hash rate advantage.

There should be a better way to support the developers. A 1-time license payment is much better.

Or, change the switching period from 90 minutes to 12 hours. For every 12 hours the developers get 7 minutes of mining time. This way it not only reduces the switch from 16 times a day to twice, but the developers will also get a more consistent payment (mining is better done continuously for an unbroken period of time).

Hello Phoenixminer, when the new version? I have 2-5% stale shares and no improvement in the Kernel with rx580 8gb

   You can combine the -minRigSpeed option with -rmode 2. This will shut down the miner and execute the reboot.bat file, which must be provided by you with the necessary command(s) to restart the rig (e.g. shutdown /r /t 00).

   The new AMD kernels in 2.8b will address both the hashrate and the stale shares. Don't expect miracles but there will be tangible improvements in both areas. With that being said, we (or any other miner) can only lower the stale shares that are caused by the kernel latency (and this is the number reported by PhoenixMiner). It can't be 10% for a long period of time - the highest we have seen is 4% with -mi 12 and 2% with the default -mi 10. With the new kernels it will be at or below 1% with -mi 12.

   No guide, but it affects the rearrangement of instructions in attempt to hide the latency of the memory. You can try each value for a minute or so (until the hashrate stabilizes), then try with 10 more or less, and so on. Once you found the two best values, try each value between them to find the best one. It is kind of long process and should be repeated for each card unless they are identical and with the same overclocking settings and BIOS-es.

   We can implement something similar but only if it works more reliable. In our testing, Claymore's auto-tuning find the right -dcri option in his miner in only one from 10-15 attempts. With such success rate we feel that it is better to stick with the default value or tune manually.


    PhoenixMiner resets the OC settings if it is closed "gracefully" with Ctrl+C in the console (but not if it is closed by clicking the X button in the top right corner of the console). However, there is no definitive (i.e. fully documented) way to reset the OC settings, so it may not work with some cards (it does work with Polaris cards and 18.x.x drivers). Note that when we apply clocks and voltages, it is always with absolute values and not offsets. A possible workaround is to add command-line option -resetoc that will force PhoenixMiner to reset the OC settings at startup. We are also considering resetting the OC settings even when the miner is closed forcibly but this may cause problems if some of the GPUs are frozen and the miner is trying to restart.

  IF it works properly. And to do this, it must work much longer than 30 seconds (like at least 10 minutes).

I don't believe for a second that pool is reporting stale shares.
If the miner see's a stale share and it isn't reported at the pool, then the pool isn't reporting them
and they're lying to you.

The pool will always report more stale shares than the miner.
So yes, the miner can't see all the stale shares, but it it see's one then there was one.

I only use AMD Cards.
And yes. It is only good for AMD

My biggest wish is that the inline tuning for AMD could be implemented for nvidia.. so that it can tune itself without having to restart.

Just read your earlier posts - so the -gt is only relevant for AMD cards?

Thanks!

I agree.
I wrote up a procedure for manually tuning the cards for the best -gt values a few pages back.
It's time consuming if you heave lots of cards but well worth the exercise.
The default is not giving users the most hashes.

I hope PhoenixMiner decides to implement the auto tuning like Claymore did.
it takes a process that can take hours down to about 1 minute.

@PhoenxiMiner
Please implement the auto tune feature in a release soon.
It's a big deal.

Same here, but better hashrate stability with phoenix for me .. Not sure what to do..

Ive had only 0.02 ETH since tuesday night, so yes, it would seem theres a drop, one thing Ive failed to understand is that (as mentioned before, each week ive been getting less and less, with 24/7 running) but how if you end up not mining for a while when you go back you almost seem to try make up for it, you seem to find a ton of shares initially and then it levels back up.  TBH with the cost of ETH going down, right now, I am wondering when I draw the line on is it cost effective.

I've just had a look at the Anorak pool some interesting facts as shown on their pool page (correct as at 15.46 UTC)

Miners Online : 155
Pool hashrate 36.23GH
Average time to find block: 25 hours
Last block found: 44 hours ago


Is it worth it in relation to text in BOLD?

Interesting, I haven't used anorak, but after reading many many posts about it I started to wonder, is Anirak's pool really reporting stale shares?

In my experience, stales shares WILL happen... eventually, statistically, so having 0 stales, it makes me wonder. Yes, Ethermine shows a varying percentage, in my case from 2 to 5% and I still dont know how to fix it beside improving the ping, which wouldn't happen, ISP's are like that.

Just a friendly poke to all who're using Anorak's pool, review IF they actually report the stales.

--
aurus

Thanks a lot for the information mate. I will setup my rig now in the lunch break to start mining on this pool and I will wait 48 hours to see the results! Ethermine has been a really bad ride for me so far. I have tried mining a lot of coins and never saw a stale/rejected shares, just on ethermine it's  staling like crazy...

Stales always will be, at least when block changes, share become stale for new block. But miner may don't send stales to the pool.

Phoenix estimates the stale shares ratio, so it's not accurate. As you know, what's accurate is the pool. 1 1/2 day mining at anorak tech, no stale at all.

Im testing with 9 rigs, in the pool Page i see 0 estales, but in Phoenix miner 1-4%

For weeks, with the same 3 RX 570 GPUs, I used to have 1-4% (4% was in "bad times") stale share rate with ethermine, recently it was 5-15% with the same settings (core 1150Mhz and mem between 2060 to 2130Mhz), although I've a HTTP internet. The miner was submitting shares with a 5ms average ping.
The last two days, I start mining at anorak tech pool (https://eth.anorak.tech/#/), not a single stale.

I briefly tried claymore 11.5, not any better.

Is anyone else also having a really smaller hashrate in comparison with, for example, last week? I've been mining and for the last 48 hours my hashrate at the ethermine pool has been 140mh/s ?! The local miner is showing constantly 30.5mh/s on all 5 cards? Is there a global hashrate drop or is it just the pool?

Ive been trying PM 2.7c on a standalone desktop with R9 390 8GB (XFX).  I know this miner is focused on RX cards (which I have many of) but I have a fair number of R9 390s and I'm having a lot of hardware control problems.

I'm getting 'failure to set -tt error -1', but setting a static fan speed works.  However, the fan speed sticks even after I close the miner.  Similarly, my clocks and voltages will set (watching in GPU-Z), but they won't reset when the miner closes.  This is a big problem since when I try to launch a second time, it seems like a negative voltage offset stacks with the first and I get BSOD, driver crash, etc.  Regardless, I pretty much have to reboot to get it to start 'fresh'.  It definitely seems faster when I can get it to run, but I have some machines that need to start and stop on demand.

MSI AB works for all my hardware settings, but I really would like the miner to handle it all and go back to stock settings when it stops.  I have a few standalone desktops with one or two GPUs that I actually use and I like them to mine when idle (scheduled task) and stop when I sit down.  I also have one dedicated rig that I run on a schedule to control heat midday.  I've been running ethminer like this; scheduled task based on idle or time.  I was about to jump to Claymore on my idle use machines simply because of the hardware control features (which ethminer lacks) so I don't have to keep switching MSI AB profiles, and that's when I discovered PhoenixMiner.

I'm just curious if these hardware control issues may be on my end or are a known issue with R9 series cards.  I have tried 3 drivers in the 18 series, but I haven't gone back to 17.  I've tried it with MSI AB reset to defaults, MSI AB completely uninstalled, AMD settings running and AMD settings not-running.  I've lowered mining intensity and slowed DAG generation and all that, but the crashes really seem to be due to ridiculously low voltages on the second run of the miner, like PM is trying to stack a negative offset each time.  Bottom line is PM doesn't release the hardware settings when it closes, at least it doesn't on this GPU and I feel like that's where my problems are coming from.  I can run PM, close it, then run something like FurMark and all my clocks and voltages are still stuck on the PM settings.

I don't mean to sound high maintenance, just want to figure this out.  If it's a known issue, hopefully it's one that will get fixed, but no big deal.  Any input would be appreciated.