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
? what gives
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:
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
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.
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.
