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

Clay-Phoenix-Ethermine-Autostarter
Phoenix,Claymore Devfee no Hash Stop ,Autostart the Miner and Go Common problem with Phoenixminer and Claymore Miner is when DEVFEE comes by and the third or fourth time does not catch Shares gives these miners warning and stops the miner, to remedy this is this startbat watchdog and this ensures that the miner starts again or if necessary restart the whole miner rig, you place the contents of the start debate of the miner in this watchdog bat, and works great, you can download it at:

Download: https://github.com/digitalpara/Clay-Phoenix-Ethermine-Autostarter

Download: https://mirrorace.com/m/1qlvn

Thanks! Using -clkernel 2 and -gt 50 for Baffin card improved performance from ~11 Mh/s to 14+ Mh/s!

Back to PhoenixMiner again!

for people who can not find phoenixminer 2.9.d in the forum here is the download link again.
https://bitcointalksearch.org/topic/m.34449237
maybe for the phoenix developer an idea to place the download link on the opening page 1 better.

Nice results there! Is the pool reporting the same, btw? I have noticed for the 12 hours I mined ETH, that the miner reported more stales than the pool  Dunno who to trust, lol, but anyway 6 cards hashing waaay better than they should be, considering that they've been running 24/7 for the last couple of months, always squeezing them to their maximum limit I still get around 31.5mh/s on each card and that's reported by the pool, not locally from the miner.

Wow, I am impressed with the results of the new 2.9b version on my rig with 5x AMD RX580 4Gb (Elpida):
2018.04.13:10:24:29.987: main *** 44:36 ***************************************************
2018.04.13:10:24:29.987: main Eth: Mining ETH on eth.coinfoundry.org:3073 for 36:54
2018.04.13:10:24:29.987: main Eth speed: 156.019 MH/s, shares: 24292/1/6, time: 44:36
2018.04.13:10:24:29.987: main GPUs: 1: 31.212 MH/s (4827) 2: 31.200 MH/s (4898) 3: 31.216 MH/s (4840/6) 4: 31.215 MH/s (4868) 5: 31.177 MH/s (4860)
2018.04.13:10:24:29.987: main Eth: Accepted shares 24292 (116 stales), rejected shares 1 (0 stales)
2018.04.13:10:24:29.987: main Eth: Incorrect shares 6 (0.02%), est. stales percentage 0.42%
2018.04.13:10:24:29.987: main Eth: Maximum difficulty of found share: 87.3 TH (!!!)
2018.04.13:10:24:29.987: main Eth: Average speed (5 min): 155.910 MH/s
2018.04.13:10:24:29.987: main Eth: Effective speed: 150.14 MH/s; at pool: 150.13 MH/s

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

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

   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.

   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.

   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:
   Then you put this .bat file in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run instead of directly running PhoenixMiner.exe.

   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.

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

   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.

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

   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.

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!

So, no love for Baffin at all?

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

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

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

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

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

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?

Where is version 2.9? Can't find it

Edit: Nvm found it.

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

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