Bitcoin Forum
October 14, 2019, 09:56:32 PM *
News: If you like a topic and you see an orange "bump" link, click it. More info.
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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 111 112 113 114 115 116 117 118 119 120 121 122 123 124 ... 193 »
  Print  
Author Topic: PhoenixMiner 4.7c: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)  (Read 196871 times)
Digital_Seytan
Newbie
*
Offline Offline

Activity: 133
Merit: 0


View Profile
April 12, 2018, 10:29:13 AM
Last edit: April 12, 2018, 01:40:16 PM by Digital_Seytan
 #1461

Phoenixminer 2.9.d is really a difference much less stale shares compared with v2.8.c, hashrate with default -mi 12 for nvidia suddenly goes up with phoenixminer 2.9.d some rigs run fixed or 999 therefore with afterburner settings something back.Thank you phoenixminer developer 2.9.d is really super with far fewer stale shares, so far it has been a long-term problem with high stale shares on all previous versions of phoenixminer. and at phoenixminer 2.9.d almost 0 stales, I do not know what you have done with this version but is really applause.Phoenixminer starting with all those percentages on the screen takes much longer, would be very nice if it would start without that is just as with ETHMiNER, hopefully you get that in the next version for each other a quick start of phoenixminer. if you need testers for upcoming new versions I like to help.

Phoenix startbat config i use Nvidia cards is here

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 eu1.ethermine.org:4444 -pool2 eu1.ethermine.org:4444 -wal 0xXXXXXXXXXXXXXXXXXXXXXXXXXX.rig1 -pass x -nvidia -proto 3 -ftimeout 120 -cdm 0 -log 0 -minRigSpeed 130.000 -rmode 2 - coin eth -coin2 eth -timeout 2200 -tstop 80 -start 70



1:First beta of 1.4.4 is here - WiNETHER 1.4.4. It can be downloaded from:
https://github.com/digitalpara/WiNETH

2:First beta of 1.4.4 is here - WiNETHER 1.4.4. It can be downloaded from:
https://mirrorace.com/m/1qikt
1571090192
Hero Member
*
Offline Offline

Posts: 1571090192

View Profile Personal Message (Offline)

Ignore
1571090192
Reply with quote  #2

1571090192
Report to moderator
1571090192
Hero Member
*
Offline Offline

Posts: 1571090192

View Profile Personal Message (Offline)

Ignore
1571090192
Reply with quote  #2

1571090192
Report to moderator
1571090192
Hero Member
*
Offline Offline

Posts: 1571090192

View Profile Personal Message (Offline)

Ignore
1571090192
Reply with quote  #2

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

Activity: 602
Merit: 55


View Profile
April 12, 2018, 11:28:28 AM
 #1462


Thanks, but I want to run 1 instance of Phoenix for nvidia and 1 instance of claymore for AMD on the same rig.
I don't have AMD 18.3 driver installed on the rig. I only have the blockchain beta which is not suitable for Phoenix miner. Claymore has run very stable on it for months and I don't want to upgrade the drivers to introduce unkown factor and downtime.
The nVidia driver on the rig is very stable as well. But if my nVidia driver is good enough for phoenix, I can start a separated instnace of cmd to run all GTX1070/1060 on the rig. Some unknown factors but no downtime. That's why I want to know what's a good version of nVidia driver to run Phoenix. I use afterburn to control OC/Voltage for nVidia cards. Thanks in advance.

I have no stability issue with the blockchain drivers and have been using phoenix since 2.6 version. 3X RX570 with bios mod.
BennyT
Full Member
***
Offline Offline

Activity: 268
Merit: 108


View Profile
April 12, 2018, 12:14:23 PM
 #1463


Thanks

Since I was able to run 8 instances of claymore in one computer, I assume I would have enough resource to do the same for phoenix then. I start 8 instance also for benchmark reason as well. Particularly I was able to measure the true output for different brand gtx 1070/1060 rx 580 gpus: eth/hour on a particular gpu.

Which nVidia driver version is consider to be good for Phoenix miner?

I've had no problems with Phoenix or other miners using the latest drivers from nvidia. If there was ever an issue, you can roll back to older versions.
terrya
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
April 12, 2018, 02:41:09 PM
 #1464

upgraded from 2.8c
stale share of 900MH/s mining rigs down from 3-4% to 1% now
share from 7XX to 8XX now
fimatiku
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
April 12, 2018, 03:01:00 PM
Last edit: April 12, 2018, 03:40:07 PM by fimatiku
 #1465

2.9d slightly higher  than 2.8c hashrate for cards with Micron memory
2.8c slightly higher than claymore 11.6

----

with cl I got 190
with 2.8c i got 191
with 2.9d i got 192

same rig same cards

but CL had it runing for 20 days no issues windows works fine
2.8c after 10 hours windows start menue non responsive had to close miner and all is working, runing 2.9d now

https://i.imgur.com/T1yGR9O.jpg


Wow I just noticed it shows how many shares each card got and if any incorrect etc... very nice

32.5 - 32.6 mhs very nice
Digital_Seytan
Newbie
*
Offline Offline

Activity: 133
Merit: 0


View Profile
April 12, 2018, 03:55:28 PM
Last edit: April 12, 2018, 04:06:56 PM by Digital_Seytan
 #1466

Phoenixminer is possible stale shares which GPU - >> total ?? and gpu 1 /? gpu2 /? gpu3 /? etc. It is easier to change settings of the GPU that causes the most stales.

http://www.resimag.com/p1/e9d607fe24.jpeg
lesjokolat
Newbie
*
Offline Offline

Activity: 112
Merit: 0


View Profile
April 12, 2018, 05:37:29 PM
 #1467

Phoenixminer is possible stale shares which GPU - >> total ?? and gpu 1 /? gpu2 /? gpu3 /? etc. It is easier to change settings of the GPU that causes the most stales.

http://www.resimag.com/p1/e9d607fe24.jpeg

It does this already. x,y,z are assigned stale shares per each GPU that caused it.

GPU 1 shares 10/x, GPU 2 shares 10/y, GPU 3 shares 10/z

Digital_Seytan
Newbie
*
Offline Offline

Activity: 133
Merit: 0


View Profile
April 12, 2018, 06:14:20 PM
 #1468

Phoenixminer is possible stale shares which GPU - >> total ?? and gpu 1 /? gpu2 /? gpu3 /? etc. It is easier to change settings of the GPU that causes the most stales.

http://www.resimag.com/p1/e9d607fe24.jpeg

It does this already. x,y,z are assigned stale shares per each GPU that caused it.

GPU 1 shares 10/x, GPU 2 shares 10/y, GPU 3 shares 10/z



I press the x / y / z keys but on the screen I get no info about STALE share per GPU unfortunately, please tell us a bit more efficiently
sidaliroy
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
April 12, 2018, 06:23:51 PM
 #1469

Where is version 2.9? Can't find it

Edit: Nvm found it.
lesjokolat
Newbie
*
Offline Offline

Activity: 112
Merit: 0


View Profile
April 12, 2018, 06:39:42 PM
 #1470

Phoenixminer is possible stale shares which GPU - >> total ?? and gpu 1 /? gpu2 /? gpu3 /? etc. It is easier to change settings of the GPU that causes the most stales.

http://www.resimag.com/p1/e9d607fe24.jpeg

It does this already. x,y,z are assigned stale shares per each GPU that caused it.

GPU 1 shares 10/x, GPU 2 shares 10/y, GPU 3 shares 10/z



I press the x / y / z keys but on the screen I get no info about STALE share per GPU unfortunately, please tell us a bit more efficiently

The screen output for each line of the GPU summary you have a list of all GPUs and the shares found for each.(If and when a stale is found then beside each count you would have a secondary total.)

GPU 1 - (105/3) in this case the 105 is found shares, the 3 are the stales)

Make sense now?
Digital_Seytan
Newbie
*
Offline Offline

Activity: 133
Merit: 0


View Profile
April 12, 2018, 06:51:54 PM
 #1471

Phoenixminer is possible stale shares which GPU - >> total ?? and gpu 1 /? gpu2 /? gpu3 /? etc. It is easier to change settings of the GPU that causes the most stales.

http://www.resimag.com/p1/e9d607fe24.jpeg

It does this already. x,y,z are assigned stale shares per each GPU that caused it.

GPU 1 shares 10/x, GPU 2 shares 10/y, GPU 3 shares 10/z



I press the x / y / z keys but on the screen I get no info about STALE share per GPU unfortunately, please tell us a bit more efficiently

The screen output for each line of the GPU summary you have a list of all GPUs and the shares found for each.(If and when a stale is found then beside each count you would have a secondary total.)

GPU 1 - (105/3) in this case the 105 is found shares, the 3 are the stales)

Make sense now?

sorry i am using phoenixminer with NVIDIA GPU ,and see only total stale shares and not for every GPU
terrya
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
April 12, 2018, 07:25:48 PM
 #1472

The connection issue still persist.
if you reboot router with dynamid ip
the miner cant connect to ethermine.org pool
you need to manual close and relaunch the program to connect
70-80% of rigs have this problem occur
while some can connect after router reboot
kadok29
Newbie
*
Offline Offline

Activity: 36
Merit: 0


View Profile
April 12, 2018, 09:06:30 PM
 #1473

The connection issue still persist.
if you reboot router with dynamid ip
the miner cant connect to ethermine.org pool
you need to manual close and relaunch the program to connect
70-80% of rigs have this problem occur
while some can connect after router reboot


i'm agree... The connection issue still persist.
pinamalina
Jr. Member
*
Offline Offline

Activity: 47
Merit: 1


View Profile
April 12, 2018, 09:32:14 PM
 #1474

Report of first 24hrs on PhoenixMiner 2.9d (migrated from 2.8c).

Environment: 52 GPU (45x RX580/8GB, 7x 1070/8GB) in four rigs of 13 cards each.

Results:
  - Hashing rate: Increased a bit: Before: 1.630 GH/s, now 1.633 GH/s ~ 0.12% increase. The increase is most notable on Nvidia cards.
  - Power Consumption: Decreased for few watts: e.g. on one rig from 1630 to 1620W on average, measured on the wall. A slight temperature drop in line with power consumption.
  - Stale share: Increased a bit as reported by the ethermine.org pool, before 3-4%, now 4-5% with drops to 2% occasionally. Was < 3% on Claymore 11.5
  - Stability: Stable, occasional hashing drops on some cards e.g. form 31MH/s to 24 for a 10-20 sec, then recovering back to normal 31 MH/s. Did not observe that before.

Comments:
  - In my opinion the "-logsmaxsize <n> Maximum size of the logfiles in MB. The default is 200 MM"; The default value of 200Mb is to high and cannot be normally edited by most editors. The default should be no more than e.g. 10MB or if you must, 50Mb.
  - Missing a feature: Auto tune of the GPU tuning parameter /-gt/; Similar to Claymore -dcri auto tune).
  - The 2.9d is officially released as an unofficial version with full support. Really Smiley Why not just stick to the usual sw naming convention like calling it "alpha"; a limited test version that might get new functionalities until released as final.

Verdict: Works like a charm out of the box. Thumbs up!
pinamalina
Jr. Member
*
Offline Offline

Activity: 47
Merit: 1


View Profile
April 12, 2018, 09:44:47 PM
 #1475

The connection issue still persist.
if you reboot router with dynamid ip
the miner cant connect to ethermine.org pool
you need to manual close and relaunch the program to connect
70-80% of rigs have this problem occur
while some can connect after router reboot


i'm agree... The connection issue still persist.

I did observe this problem when my dynamic IP changed by the ISP. However in my case Phoenix 2.8c auto-recovered from the situation on its own.
It attempted to connect to the main pool several times waiting 20 sec in between and then after 3 or so failed attempts successfully connected to the next pool from my epools.txt.

Possible workaround: Add second (or more) pool(s) to the epools.txt list. You can add the same pool there twice.
Example of epools.txt:
# Ethermine.org
# Main pool listed in the config.txt file: POOL: eu1.ethermine.org:4444,   WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0
POOL: us1.ethermine.org:4444,   WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0
POOL: us2.ethermine.org:4444,   WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0
POOL: asia1.ethermine.org:4444, WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0
POOL: asia2.ethermine.org:4444, WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0
lncm
Member
**
Offline Offline

Activity: 323
Merit: 11


View Profile
April 12, 2018, 09:49:01 PM
 #1476

So, no love for Baffin at all?
murgorx
Member
**
Offline Offline

Activity: 252
Merit: 11


View Profile
April 13, 2018, 07:01:21 AM
 #1477

Sickest Ethash miner! I am pulling almost 32MH/S on my Micron mem RX580! Settings 1240/2200, both cvddc and mvddc @ 950. The power draw is not of a big concern of me, since my electricity is 0.06cents/h. the 2.9 version of the miner has been reporting even less stale shares - for the last 48 hours I have submitted less than 50 shares according to the pool!!
Insane performance!
PhoenixMiner
Member
**
Offline Offline

Activity: 226
Merit: 13


View Profile
April 13, 2018, 07:09:46 AM
 #1478

What is the best version for nVidia driver to run PhoenixMiner 2.8c or 2.9d?
I open multiple instances to run claymore on RX580 and Phoenix on GTX1070/1060 on the same rig, right?
   Frankly, we just install the latest Nvidia drivers whenever we set up a new mining rig. Some of our test rigs run quite old driver versions too, and we don't see much difference. As always, YMMV so if you may find that one driver works better for you. In any case the speed difference won't be anything to write home about but there may be difference in stability.
   Yes, you can use multiple instances of both Claymore and PhoenixMiner on the same rig. Just use the -di (in claymore) and -gpus (in PhoenixMiner) to force them to use different GPUs. Also you may want to change the remote management port from the default 3333 as only one of the instances will be able to use it.

Update and comparison
2.9d is actually a bit of a loss in hashrate. vega 64 virtually no change from 2.8c. fury x are lower than 2.8c 34.5 avg now

the best speed was 2.8b but stales now are virtually nil.

Regards
   You can try higher -gt values with the Fury cards with the new kernels. We found optimal performance in some of our Fury cards at about -gt 150.

To the Developer:

For some reason phoenixminer will NOT AUTO RUN using regedit but Claymore does  HuhHuhHuhHuh? what gives HuhHuhHuh

I set up all my rigs to auto log on auto mine - in case power loss or windows update or some other bulsh*t etc.........

works fine with claymore.

If I input phoenixminer.exe absolutely NOTHING HAPPENS AFTER REBOOT ..................... WTF.......................................
   PhoenixMiner looks for config.txt and epools.txt in the current folder, which may not be the folder where the PhoenixMiner.exe is placed. In your case probably you are running PhoenixMiner.exe but the current folder is not the folder where your config.txt and epools.txt files are placed so it just exits. We will make changes in the next release and if the program is started without any options, it will look for config.txt not only in the current folder but also in the folder where the PhoenixMiner.exe is placed. Alternatively, if a full path to config.txt is specified, we will look for epools.txt in the same folder.
   To fix the problem with the current release, create a small .bat file with the following content:
Code:
REM If PhoenixMiner is on other drive than C:, change the drive bellow
C:

REM Change the folder bellow to the FULL PATH (i.e. starting from the root directory) where PhonixMiner.exe is placed
cd C:\MiningSoftware\PhoenixMiner2.9d\

PhoenixMiner.exe
pause
   Then you put this .bat file in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run instead of directly running PhoenixMiner.exe.

Phoenixminer is possible stale shares which GPU - >> total ?? and gpu 1 /? gpu2 /? gpu3 /? etc. It is easier to change settings of the GPU that causes the most stales.
http://www.resimag.com/p1/e9d607fe24.jpeg
   We can show stales by GPU but it is not really a meaningful statistic (as opposed to incorrect shares which are shown by GPU). In the latest version the internal stale shares should be very low (less than 0.1% in the long run) so only the external stales remain, which are completely outside the control of (and completely undetectable by) the miner.

The screen output for each line of the GPU summary you have a list of all GPUs and the shares found for each.(If and when a stale is found then beside each count you would have a secondary total.)

GPU 1 - (105/3) in this case the 105 is found shares, the 3 are the stales)

Make sense now?
   Actually, these are the incorrect shares, not the stales. As stated above, the stales are not shown for each GPU (only as total number).

The connection issue still persist.
if you reboot router with dynamid ip
the miner cant connect to ethermine.org pool
you need to manual close and relaunch the program to connect
70-80% of rigs have this problem occur
while some can connect after router reboot
   We will try to reproduce this. At the first glance this shouldn't happen as each connection attempt is done independently for the previous one - new DNS lookup, new TCP socket, etc., so the changed IP shouldn't be of any importance.

Report of first 24hrs on PhoenixMiner 2.9d (migrated from 2.8c).

Environment: 52 GPU (45x RX580/8GB, 7x 1070/8GB) in four rigs of 13 cards each.

Results:
  - Hashing rate: Increased a bit: Before: 1.630 GH/s, now 1.633 GH/s ~ 0.12% increase. The increase is most notable on Nvidia cards.
  - Power Consumption: Decreased for few watts: e.g. on one rig from 1630 to 1620W on average, measured on the wall. A slight temperature drop in line with power consumption.
  - Stale share: Increased a bit as reported by the ethermine.org pool, before 3-4%, now 4-5% with drops to 2% occasionally. Was < 3% on Claymore 11.5
  - Stability: Stable, occasional hashing drops on some cards e.g. form 31MH/s to 24 for a 10-20 sec, then recovering back to normal 31 MH/s. Did not observe that before.

Comments:
  - In my opinion the "-logsmaxsize <n> Maximum size of the logfiles in MB. The default is 200 MM"; The default value of 200Mb is to high and cannot be normally edited by most editors. The default should be no more than e.g. 10MB or if you must, 50Mb.
  - Missing a feature: Auto tune of the GPU tuning parameter /-gt/; Similar to Claymore -dcri auto tune).
  - The 2.9d is officially released as an unofficial version with full support. Really Smiley Why not just stick to the usual sw naming convention like calling it "alpha"; a limited test version that might get new functionalities until released as final.

Verdict: Works like a charm out of the box. Thumbs up!
  Thank you for sharing your results. The -logsmaxsize option defines the max size of all log files, not a single file, so 200 MB should be adequate if you want to keep a history for the last few weeks (or months). We don't have a limit of the size of a single logfile but it may be added in the future.
   We will add auto-tuning in the next version (3.0).
   Well, it is more like a beta in that it should be stable enough for normal usage.  Grin However it is not recommended for deployment on large farms as it is not tested enough. But you are quite right that the naming convention is not ideal. We will probably switch to two channels: stable and beta, and each version will be clearly marked to avoid any confusion if it is stable or beta version.

So, no love for Baffin at all?
   Please try to use -clkernel 2 for Baffin or try to change the -gt values. We will add auto-tuning in the next version (3.0), which will make the fining of optimal parameters easier.

terrya
Newbie
*
Offline Offline

Activity: 5
Merit: 0


View Profile
April 13, 2018, 07:45:23 AM
 #1479

The connection issue still persist.
if you reboot router with dynamid ip
the miner cant connect to ethermine.org pool
you need to manual close and relaunch the program to connect
70-80% of rigs have this problem occur
while some can connect after router reboot


i'm agree... The connection issue still persist.

I did observe this problem when my dynamic IP changed by the ISP. However in my case Phoenix 2.8c auto-recovered from the situation on its own.
It attempted to connect to the main pool several times waiting 20 sec in between and then after 3 or so failed attempts successfully connected to the next pool from my epools.txt.

Possible workaround: Add second (or more) pool(s) to the epools.txt list. You can add the same pool there twice.
Example of epools.txt:
# Ethermine.org
# Main pool listed in the config.txt file: POOL: eu1.ethermine.org:4444,   WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0
POOL: us1.ethermine.org:4444,   WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0
POOL: us2.ethermine.org:4444,   WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0
POOL: asia1.ethermine.org:4444, WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0
POOL: asia2.ethermine.org:4444, WALLET: %WALLET%.%WORKER%, PSW: x, WORKER: , ESM: 0, ALLPOOLS: 0

might works but other address will have different geo location which has higher ping time thus higher stale share...
j2james
Newbie
*
Offline Offline

Activity: 61
Merit: 0


View Profile
April 13, 2018, 08:24:31 AM
 #1480

The -logsmaxsize option defines the max size of all log files, not a single file, so 200 MB should be adequate if you want to keep a history for the last few weeks (or months). We don't have a limit of the size of a single logfile but it may be added in the future.

Strange solution. Never seen that. For example in java there is RollingFileAppender (https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/RollingFileAppender.html) which creates new log file when current file has reached limit size. I waited to have the same functionality, and I think that not only me. If the current behaviour is like you have described, then can you please to use parameter 0 as recomendation do not delete logs (so limit is absent).
Pages: « 1 ... 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 111 112 113 114 115 116 117 118 119 120 121 122 123 124 ... 193 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!