Bitcoin Forum
June 24, 2021, 01:33:38 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 [60] 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 ... 459 »
  Print  
Author Topic: PhoenixMiner 5.6d: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)  (Read 664322 times)
PhoenixMiner
Member
**
Offline Offline

Activity: 338
Merit: 68


View Profile
March 24, 2018, 07:13:35 AM
 #1181

HI, is there an option to have my rig reboot i the speed drops below a set point?

I see that you can restart the miner but i want to restart the rig.

thanks, Robin
   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).

@PhoenixMiner

I really like the stability and the speed, here it comes, but,
The stale share rate is really bad.
I have all AMD cards, on another miner I get <1 % stale shares.
PhoenixMiner gets 5% to 10% stale shares.

This really needs to be looked at. The additional hash rate that I get using Phoenix is eaten up
with stale shares. I'm loosing .35% of 5 to 10% of all the shares submitted.

I know this can be solved, I've seen it solved elsewhere.

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

Is there a guide somewhere for exactly how the -gt option affects things?  What does it make changes to, and to what degree?

Thanks for the work!
   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.

Can you implement Claymore's auto tuning for best intensity per card?
   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.


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

...
@PhoenxiMiner
Please implement the auto tune feature in a release soon.
It's a big deal.
  IF it works properly. And to do this, it must work much longer than 30 seconds (like at least 10 minutes).
1624541618
Hero Member
*
Offline Offline

Posts: 1624541618

View Profile Personal Message (Offline)

Ignore
1624541618
Reply with quote  #2

1624541618
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1624541618
Hero Member
*
Offline Offline

Posts: 1624541618

View Profile Personal Message (Offline)

Ignore
1624541618
Reply with quote  #2

1624541618
Report to moderator
1624541618
Hero Member
*
Offline Offline

Posts: 1624541618

View Profile Personal Message (Offline)

Ignore
1624541618
Reply with quote  #2

1624541618
Report to moderator
1624541618
Hero Member
*
Offline Offline

Posts: 1624541618

View Profile Personal Message (Offline)

Ignore
1624541618
Reply with quote  #2

1624541618
Report to moderator
twotwosix
Newbie
*
Offline Offline

Activity: 120
Merit: 0


View Profile
March 24, 2018, 07:31:52 AM
Last edit: March 24, 2018, 08:05:53 AM by twotwosix
 #1182

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

Activity: 89
Merit: 4


View Profile
March 24, 2018, 08:11:52 AM
 #1183

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).
PhoenixMiner
Member
**
Offline Offline

Activity: 338
Merit: 68


View Profile
March 24, 2018, 09:00:15 AM
 #1184

Hello Phoenixminer, when the new version? I have 2-5% stale shares and no improvement in the Kernel with rx580 8gb
   2.8b will be released late Sunday or early Monday depending on stability during the internal tests.

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

agente
Full Member
***
Offline Offline

Activity: 236
Merit: 100


View Profile
March 24, 2018, 09:39:45 AM
 #1185

Having problem with 1060 3gb and buffer (I have 25gb of pagefile). Im back to claymore (using -eres 0).
I will wait a fix in phoenix..
Metroid
Sr. Member
****
Offline Offline

Activity: 1596
Merit: 326


Xtreme Monster


View Profile
March 24, 2018, 10:20:29 AM
 #1186

...

cvddc and mvddc do not work for AMD blockchain drivers 23 august 2017, claymore does, can you make it to work on your miner? Also, claymore stale shares are lower than your miner right now.

BTC Address: 1DH4ok85VdFAe47fSVXNVctxkFhUv4ujbR
Digital_Seytan
Jr. Member
*
Offline Offline

Activity: 186
Merit: 1

Hayat guzeldir yasamasini bilene !


View Profile WWW
March 24, 2018, 01:49:21 PM
 #1187

users of this software Stale shares on the phoenixminer 2.8.a is I think a little higher than Claymore v11.5 because with phoenixminer the hasrate is much higher, it gives a little longer processing time on the GPU, therefore if you use msiafterburner (or another software) the settings are slightly lower and de (-mi 11). helps a lot, of course information from all users of this software is welcome and new ideas, but it is very strange that phoenixminer is far behind in comparison with Claymore 11.5. Huh
I am very curious what is added to the latest version of Phoenixminer, okay devfee is slightly lower on the phoenixminer but the stale shares  4% or 5% are higher than Claymore v11.5

Hayat guzeldir yasamasini bilene !
ScalperBTC
Newbie
*
Offline Offline

Activity: 26
Merit: 0


View Profile
March 24, 2018, 02:04:14 PM
 #1188

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

And when to wait for the version for dual mining?

It is desirable (if it is possible certainly) to combine Ethash and Equihash and CryptoNight and other algorithms. That is, to combine Ethash and other algorithms (Sorry for Wishlist)

Thank you in advance for your response
murgorx
Member
**
Offline Offline

Activity: 434
Merit: 13


View Profile
March 24, 2018, 04:10:46 PM
 #1189

Hey guys, for the last week I have seen a dramatic decrease of the pool hashrate? I have been mining on ethermine and since friday on anorak.tech's pool, but both were showing 140mh/s, which last week on ethermine was still around 150-152mh/s. Due to what is this thing happening? I watched the miner for a couple of hours and it seems finding shares has become a bit harder, thus the decrease of the hashrate? May it be something with my rig or is this a general issue?
peterboy1
Newbie
*
Offline Offline

Activity: 168
Merit: 0


View Profile
March 25, 2018, 01:26:05 AM
 #1190

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

he wont implement that 12hrs or something, and so is claymore. its much easier to cheat devfee that way. you just set auto restart every 11:59hr. profit.

this is the most profitable business this time people. like the gold rush era. those who sell equipments are the one who gained.
Old_Timer
Member
**
Offline Offline

Activity: 131
Merit: 13

In the fray since 2013.


View Profile
March 25, 2018, 10:13:33 AM
 #1191

ia there a link for 2.8.a?

I can only see 2.7.c
Digital_Seytan
Jr. Member
*
Offline Offline

Activity: 186
Merit: 1

Hayat guzeldir yasamasini bilene !


View Profile WWW
March 25, 2018, 10:56:23 AM
 #1192

First beta version of 2.8 branch: PhoenixMiner 2.8a. It can be downloaded from here:
  https://mega.nz/#F!PZ1jXBQY!4ttKHoWGPCiYM-2kgK_uTQ

  Here are the checksums to verify the download:
Code:
   File: PhoenixMiner_2.8a.zip
   SHA-1: 00fc3c698fadb7187632bf4e7ab9ecf0afd1c9a1
 SHA-256: f3f4857ac85f31f2bee7a3d8b9c9c526c7dec0433c72b4c47555b47911323d00
 SHA-512: f736bcd6a0c4b172f41452d8b1c324efc978540b5f4addc8a3387d23cb872538838bde0895f826649b5ba493bfd240b242edf0a91fc02d18d92fdc814ed7eac3

   Note that this is not an official release. The changes are:
  • Small kernel stability improvements that also may (very) slightly increase the speed of Nvidia cards
  • CPU utilization during normal operation is lowered by about a factor of 10 regardless of the number of GPUs
  • Added support for -tstop and -tstart options to stop mining on given GPU if the temperature rise above specified value and restart it after it cools down below -tstart temperature
  • Fixed the problem with console window freezing after scrolling
  • Implemented new -gpow n option to lower the GPU utilization (the value n is the desired GPU utilization in percent; default: 100)
  • Implemented the -li option to lower the intensity (use this instead of -gpow if you are already using -mi with low values)
  • Improved GPU speed statistics, using moving average window for each GPU. You can change the size of the window with the -gswin n option (n is between 5-30 seconds; default 15; use 0 to revert to the old way of using 5 second "quants" which are independent of each other)
  • You can now specify GPU number above 9 by typing three-digit sequence at the console (e.g. type 011 to pause or resume GPU11)
  • Added support for the miner_getstat2 remote monitoring request
  • Show the SSL and HTTP schemes to indicate the type of connection
  • The command-line options are now case-insensitive

First beta version of 2.8 branch: PhoenixMiner 2.8a. It can be downloaded from here:
  https://mega.nz/#F!PZ1jXBQY!4ttKHoWGPCiYM-2kgK_uTQ

Hayat guzeldir yasamasini bilene !
Jbodz83
Newbie
*
Offline Offline

Activity: 124
Merit: 0


View Profile
March 25, 2018, 11:15:36 AM
 #1193

Phoenix provides way better hashrate, however, higher stale share in return... one more thing i noticed is that..

PM can push my 570 4gb GPU up to 29.7Mhs while CM gives me error whenever i push my GPU at the same speed while using PM.

2nd thing is, PM keeps my CPU temp lower around 41-43 under 24hrs mining, while CM could hit my CPU temp up to 50-52? any reason? does CM has  larger CPU allocation.?
timbojames
Newbie
*
Offline Offline

Activity: 2
Merit: 0


View Profile
March 25, 2018, 12:22:13 PM
 #1194


    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.


Thanks for responding, that info is helpful.  I did actually notice that even on reboot, the hardware settings previously set in PM are still active.  But, like I said, I've been shutting down with a taskkill.  I will continue to experiment.  Considering that you specify a voltage in mV and not a mV offset I could not figure out the problem I'm seeing with super low voltages.  If I reset my GPU using MSI AB (I didn't know there was a -resetoc command) and I run PM with a undervolt, say 1050mV on the core.  It goes off and voltage looks good.  Then if I close (the wrong way, I know), the 1050mV core voltage persists, but I understand why now.  What is still a mystery, is that when I launch PM again, with the same 1050mV setting in my bat, then I see like 930mV in GPU-Z and I get artifacts leading to either driver crash or BSOD.  So I still can't figure that one out.  Again, this is on an R9 390 / Hawaii.

Regardless, thanks for the great attentiveness to user issues!
BennyT
Full Member
***
Offline Offline

Activity: 267
Merit: 108


View Profile
March 25, 2018, 12:56:09 PM
 #1195

2.8 crashes one of my rigs every 3-4 hours and needs manual intervention. Can’t really figure it out.
playfast
Jr. Member
*
Offline Offline

Activity: 131
Merit: 3


View Profile
March 25, 2018, 06:35:23 PM
 #1196

Guess I'm in the minority as I get less stale shares with Phoenix 2.7c vs. Claymore 11.5, so Phoenix is more profitable for me.
The only real advantage Claymore has for me is better hashrate stability if a re-connect is needed, if Phoenix is disconnected the hashrate becomes messed up after re-connect and a full system reboot is needed.
janding
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 25, 2018, 07:27:06 PM
Last edit: March 25, 2018, 09:59:31 PM by janding
 #1197

Guess I'm in the minority as I get less stale shares with Phoenix 2.7c vs. Claymore 11.5, so Phoenix is more profitable for me.
The only real advantage Claymore has for me is better hashrate stability if a re-connect is needed, if Phoenix is disconnected the hashrate becomes messed up after re-connect and a full system reboot is needed.

I wish that was the case for me. I much want to use PM. Overall I think PM is a superior miner except for that one
issue. I don't know why, but with the same clocks and voltage setting on both miners I get <1% stale shares with Claymore
and 4 to 8% with PM. Looking forward to trying the 2.8b when it comes out.
janding
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 25, 2018, 07:42:40 PM
Last edit: March 25, 2018, 09:59:57 PM by janding
 #1198

Guess I'm in the minority as I get less stale shares with Phoenix 2.7c vs. Claymore 11.5, so Phoenix is more profitable for me.
The only real advantage Claymore has for me is better hashrate stability if a re-connect is needed, if Phoenix is disconnected the hashrate becomes messed up after re-connect and a full system reboot is needed.

I wish that was the case for me. I much want to use PM. Overall I think PM is a superior miner except for that one
issue. I don't know why, but with the same clocks and voltage setting on both miners I get <1% stale shares with Claymore
and 4 to 8% with PM. Looking forward to trying the 2.8b when it comes out.


I would like to ask you a few questions to try to get to the reason you have good luck with stale shares with PM and I don't.
(If you don't mind )

How many GPU's do you have ?
Are they all AMD cards ?
Are you overclocking or are they stock settings ?
What is your hash rates ?
What intensity do you have them set ?

Thanks for any information. I would really like to get to the bottom of this.





playfast
Jr. Member
*
Offline Offline

Activity: 131
Merit: 3


View Profile
March 25, 2018, 10:11:10 PM
Last edit: March 25, 2018, 10:35:42 PM by playfast
 #1199

I would like to ask you a few questions to try to get to the reason you have good luck with stale shares with PM and I don't.
(If you don't mind )

How many GPU's do you have ?
Are they all AMD cards ?
Are you overclocking or are they stock settings ?
What is your hash rates ?
What intensity do you have them set ?

Thanks for any information. I would really like to get to the bottom of this.

I have a very cheap rig, it usually goes 12+ hours without a single stale share on Phoenix, get at least 1-4 stales every 2 hours on Claymore.

3x AMD rx 560 2gb MSI Aero - no additional power connectors needed
PCIE Risers using 4-pin molex connectors
Clockspeed 1181core/2130mem with MSI Afterburner, +25% power limit, no change to voltages, disable ULPS
PBE one click bios modded
Hash rates ~15.75 mh/s each, currently mining MUSIC on MiningPoolHub
Phoenix 2.7c Intensity setting -mi 12 -gt 34
Generic Foxconn mobo (came with HP slimline desktop)
Generic 420w PSU
Athlon II X3 3.4 ghz underclocked to 1.3 ghz undervolted to 0.8v
4gb DDR3-1333
Windows 10 Home with Fall Creators Update
virtual memory swap file 16gb
using high performance power setting
all OS visual effects disabled
bcdedit: disabledynamictick No
AMD Crimson Drivers 17.11.4 on Graphics Mode
*Adrenalin drivers and Compute mode just make things worse for me, maybe because my cards only have 2gb vram? not sure why
janding
Newbie
*
Offline Offline

Activity: 140
Merit: 0


View Profile
March 25, 2018, 10:35:12 PM
 #1200

I would like to ask you a few questions to try to get to the reason you have good luck with stale shares with PM and I don't.
(If you don't mind )

How many GPU's do you have ?
Are they all AMD cards ?
Are you overclocking or are they stock settings ?
What is your hash rates ?
What intensity do you have them set ?

Thanks for any information. I would really like to get to the bottom of this.

I have a very cheap rig, it usually goes 12+ hours without a single stale share on Phoenix, get at least 1-4 stales every 2 hours on Claymore.

3x AMD rx 560 2gb MSI Aero - no additional power connectors needed
PCIE Risers using 4-pin molex connectors
Clockspeed 1181core/1230mem with MSI Afterburner, +25% power limit, no change to voltages, disable ULPS
PBE one click bios modded
Hash rates ~15.75 mh/s each, currently mining MUSIC on MiningPoolHub
Phoenix 2.7c Intensity setting -mi 12 -gt 34
Generic Foxconn mobo (came with HP slimline desktop)
Generic 420w PSU
Athlon II X3 3.4 ghz underclocked to 1.3 ghz undervolted to 0.8v
4gb DDR3-1333
Windows 10 Home with Fall Creators Update
virtual memory swap file 16gb
using high performance power setting
all OS visual effects disabled
bcdedit: disabledynamictick No
AMD Crimson Drivers 17.11.4 on Graphics Mode
*Adrenalin drivers and Compute mode just make things worse for me, maybe because my cards only have 2gb vram? not sure why

Thanks for that.
We're mining on different pools so that makes things a little different.
But we using the same -mi settings, also same drivers.
I'll be running some new test.
appreciate the response.

Pages: « 1 ... 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 [60] 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 ... 459 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!