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

janding

jr. member

Activity: 170

Merit: 6

Quote from: gsrcrxsi314 on March 25, 2018, 10:43:15 PM

the miner. nanopool doesnt report stales %

Then you have no idea what you stale shares are.
That number from the miner is totally worthless. That's why I wish PM would remove that from the display.
The number reported from the miner is useless. Only the pool knows if the share is stale.

That constantly confused everyone when they see that low number in the miner.
I think they leave it there so people will think they are getting this really great stale share rate.

I get 1 or 1.5% on the miner also. But the EtherMine pool shows the actual real stale shares submitted.
I have 4 to 8% stale shares at the pool sometimes a little higher. That's the only place it counts.

Even PM states that that number is not accurate if you look up previous post's from them explaining that
number.

gsrcrxsi314

member

Activity: 367

Merit: 34

the miner. nanopool doesnt report stales %

janding

jr. member

Activity: 170

Merit: 6

Quote from: gsrcrxsi314 on March 25, 2018, 10:40:12 PM

i get low stales on my rigs with PM, about 1.5% or less on average. both AMD and NVIDIA based rigs.

AMD:
PM 2.7c
6x RX 570 4GB
2x RX 580 4GB
each card is BIOS modded for core/mem clocks as well as timing patches
no software based OC
18.1.1 drivers (in compute mode)
total hashrate 228MH
nanopool ETH
stales: 1.47%

NVIDIA:
PM 2.7c
1x 1080ti
5x 1060 6GB
1x 1060 3GB
BIOS modding not possible with Nvidia cards
Afterburner with cards underclocked core and OC mem (600-900 oc mem depending on card)
390.77 drivers
total hashrate 182MH
nanopool ETH
stales: 0.76%

Are these numbers from the pool or the miner ?

gsrcrxsi314

member

Activity: 367

Merit: 34

i get low stales on my rigs with PM, about 1.5% or less on average. both AMD and NVIDIA based rigs.

AMD:
PM 2.7c; default -mi values
6x RX 570 4GB
2x RX 580 4GB
each card is BIOS modded for core/mem clocks as well as timing patches
no software based OC
18.1.1 drivers (in compute mode)
total hashrate 228MH
nanopool ETH
stales: 1.47%

NVIDIA:
PM 2.7c; default -mi values
1x 1080ti
5x 1060 6GB
1x 1060 3GB
BIOS modding not possible with Nvidia cards
Afterburner with cards underclocked core and OC mem (600-900 oc mem depending on card)
390.77 drivers
total hashrate 182MH
nanopool ETH
stales: 0.76%

janding

jr. member

Activity: 170

Merit: 6

Quote from: playfast on March 25, 2018, 05:11:10 PM

Quote from: janding on March 25, 2018, 02:42:40 PM

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.

playfast

jr. member

Activity: 131

Merit: 3

Quote from: janding on March 25, 2018, 02:42:40 PM

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

jr. member

Activity: 170

Merit: 6

Quote from: janding on March 25, 2018, 02:27:06 PM

Quote from: playfast on March 25, 2018, 01:35:23 PM

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.

janding

jr. member

Activity: 170

Merit: 6

Quote from: playfast on March 25, 2018, 01:35:23 PM

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.

playfast

jr. member

Activity: 131

Merit: 3

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.

BennyT

full member

Activity: 259

Merit: 108

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

timbojames

newbie

Activity: 2

Merit: 0

Quote from: PhoenixMiner on March 24, 2018, 02:13:35 AM

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!

Jbodz83

newbie

Activity: 124

Merit: 0

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

Digital_Seytan

jr. member

Activity: 222

Merit: 2

[email protected]

Quote from: PhoenixMiner on March 19, 2018, 08:49:11 AM

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

Old_Timer

member

Activity: 131

Merit: 13

In the fray since 2013.

ia there a link for 2.8.a?

I can only see 2.7.c

peterboy1

newbie

Activity: 168

Merit: 0

Quote from: yo_mama on March 24, 2018, 03:11:52 AM

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.

murgorx

member

Activity: 443

Merit: 13

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?

ScalperBTC

newbie

Activity: 35

Merit: 0

Quote from: PhoenixMiner on March 24, 2018, 04:00:15 AM

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

Digital_Seytan

jr. member

Activity: 222

Merit: 2

[email protected]

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

Metroid

sr. member

Activity: 2142

Merit: 353

Xtreme Monster

Quote from: PhoenixMiner on March 24, 2018, 04:00:15 AM

...

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.

agente

full member

Activity: 239

Merit: 100

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

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