@Phoenixminer what u think about ETH+BYTOM?
are you preparing a dual solution for ETH + ZIL
cause the ZIL mainnet should start on 31st January
Hey guys, any one compiled support for NRG ( energi ) yet?
I see a bright future for this coin just as eth did back in the day!
Cheers peeps and HODL for now.
We can't comment on the future support for any new coins as we have been burned in the past by this. We can promise you that we will announce any news if and when we are close to releasing it but not too far in advance to avoid false hopes and disappointment. For example, we have a working ProgPOW implementation in our internal test version and will definitely be released when there is firm date or at least decision about switching any of the major coins to ProgPOW. I have small drop (1-2%) in hashrate on GTX1070 after switching to 4.1 from 3.5.
Is that normal ?
It shouldn't be - please check if the hashrate is different if you mine a coin with lower DAG (like UBIQ, etc) or test with -bench 100 for example and then compare with -bench 250 results. We are noticing a small drop in the hashrate of the GTX10x0 cards with ever increasing DAG size but nothing major, so this may be the reason. Also, the Nvidia kernels were changed in the newer versions so this can conceivably be a reason too but in our testing GTX1070 is actually faster with the new drivers. We may provide a way to switch between the different kernel implementations like with -clkernel for AMD cards to solve similar issues with strange card behavior. Miner needs support for new AMD 19.2.1 drivers.
4.1c with -clKernels 3 didn't start at all.
We are adding support for 19.2.1 in the 4.2 development version, for now please don't upgrade to 19.2.1. We have also resolved the problems with fan control with the latest AMD drivers (19.x), which will hopefully also solve any fan control issues with the older AMD drivers, which are experienced by some of the PhoenixMiner users. |
|
|
|
Which driver would you recommend for Vega 56s? And is there perhaps any other parameter that you suggest I vary in particular to increase the hash rate?
Thanks in advance for your reply. Phoenix, keep up the good work. I really like your miner!
In terms of hashrate there really isn't much difference but in terms of stability 18.5.1 was best for us. However we don't push our test rigs to much in order to be able to clearly determine if a problem or a crash is caused by hardware pushed over the edge or software bug. Getting errors with clkernel 3
gpu 7: clenqueueCopyBuffer (-4)
Thread(s) not responsding. Restarting
gpu 9: clenqueueCopyBuffer (-4)
gpu 8: clenqueueCopyBuffer (-4)
gpu 10: clenqueueCopyBuffer (-4)
gpu 11: clenqueueCopyBuffer (-4)
gpu 13: clenqueueCopyBuffer (-4)
gpu 12: clenqueueCopyBuffer (-4)
I have 3 identical rigs (13x radeon 570 8gb). Rig 1 is working (speed rised from 408 to 411). Rig 2 working after restart. Rig 3 is not working, have to use clkernel 1.
-clkernel 3 doubles the size of DAG files, so make sure that you have big enough page file for 13 cards with double DAG buffers (i.e. 13 x 3 + 4 = 82 GB). Hi guys, first post.
I've done a couple extensive test using Pheonix 4 and claymore 11.8. I've noticed claymore is finding alot more blocks solo mining in a "pool".
I've also noticed in task manager that claymore shows one gpu use plus gpu 3d -0 on the right side of the task manager. It's the same gpu coming up everytime.
Now Phoenix will show different gpus popping up in there randomly, the question id like to know is, would this affect solo mining in any way? Because honestly, I'm getting twice the amount of blocks on claymore at a slightly lower speed ( yes I've underclocked all cards alot lower than recommended to see if the load on cards was too much to solve problems successfully.. but it didn't make much difference, pushing them too hard on the other hand, did.( and wasn't getting memory errors))
So, can pheonix miner actually solo mine, or is it just for pool mining?(even though I'm soloing on a pool)
I'm just not sure how the miner works, how a pool miner would be diff from a solo one, is it telling the cards to go about solving a block any differently? Because this seems too consistent for claymore to be finding more blocks..
P.s has anyone made a gui program to monitor the efficiency of each card, just to see if it could be doing better, I know some cards like slightly slower speeds to be more efficient..... talk about f"ing pedantic..
I'd love a reply from a miner developer!
Thanks fellow miners.
There is no difference between solo mining and pool mining as far as the hashrate goes. If you are testing under the same conditions (i.e. the same pool and difficulty) then this is just bad luck. Taja, I just updated PhoenixMiner from 4.0b to 4.0c on a rig that mines at eu1. I don't see connection problems on both versions, but my address is like this: eu1.ethermine.org:5555.
I tried eu1.ethpool.org now and I have this error: Unable to establish secure connection to ssl://eu1.ethpool.org:3333: wrong version number
Ethpool doesn't support SSL, you must use -pool eu1.ethpool.org:3333 with it (note the missing ssl://). I also had a sporadic, but this lasts for more than 12 hours.
I have both servers.
I just wanted to see if anyone else has problems with eu server.
One of our test rigs constantly mines to eu1.ethermine.org and we have had similar issues with it as well as large number of stale shares for about an hour and half a few days ago because the shares weren't confirmed by the pool for a few minutes or so. These are probably temporary technical issues but it is always wise to setup fallback pool (or few fallback pools in epools.txt) for such cases. |
|
|
|
Today I launched Phoenix miner 4.1c in dual mode with blake2s on three R9 290. They recently gave about 23 mh/s on Ether in solo. Unlike the RX series, there is no support in AMD drivers for a large DAG size for old cards, so their speed, which was once 30-31 max, has seriously decreased. Got a fantastic speed in the miner window (45 mh/s). Blake2s showed 1300 mh/s, but there were no shares at all.
I was very pleased, but after checking on the pool (Ethermine) it turned out that these are only numbers in the miner's console. The real speed remained 22-23 mh/s as it was earlier.
We have tested extensively with R9 390, which is virtually the same as 290. Most probably your drivers aren't recognized properly. Please check the logs - you will see a yellow warning message "Unknown OpenCL driver version! Hashrate and stale shares may suffer". Here is the list of supported drivers for Windows: 15.12, 17.7.2, 17.8-BETA (Blockchain drivers), 17.8.x, 17.9.x, 17.10.x, 17.11.x, 17.12.x (avoid these, some bugs), 18.x.x, 19.1.1 If you are using one of the supported drivers but the problem still persists, please send us the first few pages from the log file to diagnose the problem. I am using 4.0B without any issues.
Does this only affect if the miner crash and have to restart?
The DAG issue was already solved in 4.0b (it supports DAGs over 235). So, you don't need to upgrade unless you want some of the other new features. Just wanted to post a little thank you for your continued work and the new turbo core.
Using 4.1c with the 19.1.1 Adrenalin drivers and my RX580... stable all week and hitting just slightly over 32 MH/s.
Thank you, always nice to hear!  |
|
|
|
Hello
I use Phoenix since last spring. At first, I used it for Nice Hash and did not experience any problems, an excellent miner.
Since last summer I switched to ethermine pool and everything worked fine. But from the end of autumn I constantly try to return to Nice Hash, but the miner constantly stops working. it shows an error after allocating DAG buffer. (this is visible on the screenshot of the page) In the topic such a problem is indicated, but it says that the problem lies in the small swap file. The size of my page file is more than 30 GB per 6 1080ti video cards. At the same time, the phoenix works great on the ezermine pool. And only if I switch to Nice hash - then this problem occurs. What should I do so that the phoenix could work for Nice Hash.
My system is Windows 7. Video cards on this rig are 5 pieces of 1080 ti, power supply units 2 pcs corsair HX1200. RAM 4 GB, Video card driver 417.71, PhoenixMiner 4.1c
The page file should be enough for six cards. Instability during DAG generation could indicate too much overclocking - try to lower the memory overclock a little (especially if the crashes occur on the same GPU). Although your PSUs seem more than enough for the system, you can also try the option -gser 1 (or bigger value, if 1 doesn't help). Finally, you can also try to set -gpureset 0 . If nothing helps, please cut the last few hundred rows from the log file before the crash and send it to us (via PM for example) to see what is going on. Hello ,
What are the best setting for VEGA 56 and 64 for ETH ?
Depends on the card but basically you have to experiment a little - overclock the memory as much as it can without losing stability and lower the core clock as much as you can without affecting the hashrate too much (the temperatures and the power consumption depend mostly on the core clock). Also, make sure that the temperature is kept no more than 60-64 C because the memory is stacked on the chip and can get quite hot even the reported temperature is relatively low. |
|
|
|
What is the best driver for ethereum? Im using 18.6.1
In terms of hashrate there is no big difference. We found that 18.5.1 are the best as far as stability goes but YMMV. i use Adrenalin 2019 Edition 18.12.2 and rx580 8gb but in this new 4.X ver i can't use -tt and -tmax and everything about fan control is not working
in ver 3.5 i set this and worked perfectly
-tt 47
-tmax 52
-fanmin 10
-fanmax 55
but now i use the same commend but when gpu go to 59 degree fan start on 24% and after it's cooling they be shutdown and again this Repeat 59start .........
This is most probably driver related. Downgrade to 18.5.1 or similar drivers. There are hardware control bugs in the latest AMD drivers. We will try to think of some workaround but the for now the best solution is to stay away from the latest drivers. Noticed the same thing with the latest version and some RX580 under Linux.
Had -tt set to 68 and one GPU kept creeping up way past 80 degrees and the fan was idling at 23%.
-tt is not sported under Linux yet. Sadly 4.1c does not support 19.1.1, as it gives the Unknown OpenCL version error and suffers a hashrate loss because of it.
-clkernel 3 mode does not even work with it. ( clSetKernelArg (-49) )
I have 19.1.1 installed and latest version of miner works normal. RX 580 8 Gb Windows 10. That`s strange... Well, I guess I can go back to 18.12.3 until we get a fix.
2019.01.19:21:21:33.279: main Phoenix Miner 4.1c Windows/msvc - Release build
2019.01.19:21:21:33.279: main Cmd line: -pool @@@
2019.01.19:21:21:33.279: main No CUDA driver found
2019.01.19:21:21:35.924: main OpenCL driver version: 19.1.1
2019.01.19:21:21:35.924: main Unknown OpenCL driver version! Hashrate and stale shares may suffer
2019.01.19:21:21:35.924: main OpenCL platform: OpenCL 2.0 AMD-APP (2348.3)
2019.01.19:21:21:35.924: main Ignoring old OpenCL driver(s), using driver version 19.1.1
2019.01.19:21:21:35.924: main Available GPUs for mining:
2019.01.19:21:21:35.924: main GPU1: Radeon (TM) RX 480 Graphics (pcie 1), OpenCL 2.0, 8 GB VRAM, 36 CUs
2019.01.19:21:21:36.002: main ADL library initialized In your log we can see that you have two versions of the drivers mixed up. The 19.1.1 are recognized properly but there are others too (probably "leftovers" from the previous driver version). You should use DDU to completely remove the drivers and then install 18.5.1 or other drivers besides 18.12.x and 19.1.x, which seems to cause problems. I see totally minuscule reported hasharete improvement with "3" kernels, wonder if there would be any real hashrate improvement.
The real hashrate improvement will be the same in the long run. However make sure to check your power consumption as it may increase in some cases, negating the benefit of the slightly higher hashrate. |
|
|
|
PhoenixMiner 4.1c is the new stable release. You can find the download link and other information in the first post of this thread. If you have already downloaded and installed it, there is no need to do this again - there is no change from 4.1c that was published as a beta version. I can`t see if I can use -Kernel option per GPU. Is it impossible at all or it is miner limitation?
I have a rig with one RX580 8Gb and four RX570 4Gb and wanna try turbo kernels. Any suggestions?
Yes, you can use -clkernel 3 only for some of the GPUs. Even if you set -clkernel 3, if given GPU doesn't have enough video memory for double DAG, it will switch to -clkernel 1. For example if you want to use the turbo kernels for the first GPU only from a five GPU rig, use the following command line option: -clkernel 311111Hi
have there real problems, when mines with R9 390 u. R9 390X GPU's .....
For some months, the hashrate is decreasing continuously from formerly about 33 Mhs / s to about 25.9 Mhs / s even though the R9 390 (X) of the DAG Epoch problem should not be affected at all ...
have any idea to get back 33 Mh/s
Resiste the DAG Epoch
This is caused by the size of the TLB, which is too small for the current DAG sizes and causes constant eviction from the TLB cache. AMD released the "compute mode" fix for RX4x0 and RX5x0 cards, which simply increased the memory page size. However there is no such fix for 290/390 cards. Probably there is no way to increase the page size on these cards because of hardware limitations but only AMD knows for sure. You can either mine coins with lower DAG (basically everything except ETH and ETC), or accept the hashrate drop (but it will get gradually worse over time). 2019.01.16:19:39:00.717: main Phoenix Miner 4.0b Windows/msvc - Release build
2019.01.16:19:39:00.717: main Cmd line: -pool ssl://eu1.ethermine.org:5555 -pool2 ssl://us1.ethermine.org:5555 -wal 0x008c26f3a2Ca8bdC11e5891e0278c9436B6F5d1E.Rig001
2019.01.16:19:39:00.717: main No CUDA driver found
2019.01.16:19:39:06.406: main Unknown OpenCL driver version! Hashrate and stale shares may suffer
2019.01.16:19:39:06.406: main OpenCL platform: OpenCL 2.1 AMD-APP (2766.5)
2019.01.16:19:39:06.406: main Available GPUs for mining:
how do i fix this problem?
You have upgraded your driver to version that is not yet supported by PhoenixMiner (see the line Unknown OpenCL driver version! Hashrate and stale shares may suffer in the log, it will be printed as yellow warning on your screen when the miner starts). It is not a good idea to update to drivers that are newer than the release of PhoenixMiner you are using because this means we weren't able to test this release of PhoenixMiner with these drivers and they probably won't work well (or at all). To fix the problem either upgrade to PhoenixMiner 4.1c, which supports AMD drivers up to and including 19.1.1. hi all good with PhoenixMiner until some hours ago i have more than one rig all nvidia and all with these error any idea with ?  Have the same problem since 4 hours. My rig works pver year without problems but today i've seen error with CUDA.
CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
GPU1 initMiner error: an illegal memory access was encountered
CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
GPU2 initMiner error: an illegal memory access was encountered
or
CUDART error in CudaProgram.cu:127 : an illegal memory access was encountered (77)
CUDA error in CudaProgram.cu:102 : an illegal memory access was encountered (700)
GPU2 initMiner error: an illegal memory access was encountered
GPU1 initMiner error: an illegal memory access was encountered
Anyone know what to do with this? Virtual memory is fine.
I started getting crash on dag creation on one rig some time in the middle of the night running Phoenix Miner 2.8... Now today all my rigs running 2.8 crash... Would think it's something that Windows pushed, even tho I have Windows Update disabled... Hopefully someone can figure it out...
(also to all miners experiencing problems with PhoenixMiner 3.5 and below versions when trying to create the DAG): The versions of PhoenixMiner before 4.0 only support DAG epoch up to 235. ETC passed epoch 235 a few weeks ago, and recently ETH also passed DAG epoch 235 and is now on 236. The unfortunate result is that the old version(s) of PhoenixMiner won't be able to create DAG or mine ETH or ETC any more - you must upgrade to PhoenixMiner 4.x. We have printed this warning here during the release of PhoenixMiner 4.0 but admittedly we could have done much better job with making it visible. We will pin this message in the first post too. After trying I also found 4.0b version does work now although it wasn’t working well before additionally it runs my rtx2070s hash a bit slower than versions 3.5 did
We are working on RTX20x0 optimizations but they won't be ready until the next release.
|
|
|
|
I confirm, after updating the software to the latest 4.0b - it is working correctly.
Also 4.0b start working. But WTF it was with ver.3.5D & 3.0C ? Developers can explain? (also to all miners experiencing problems with PhoenixMiner 3.5 and below versions when trying to create the DAG): The versions of PhoenixMiner before 4.0 only support DAG epoch up to 235. ETC passed epoch 235 a few weeks ago, and recently ETH also passed DAG epoch 235 and is now on 236. The unfortunate result is that the old version(s) of PhoenixMiner won't be able to create DAG or mine ETH or ETC any more - you must upgrade to PhoenixMiner 4.x. We have printed this warning here during the release of PhoenixMiner 4.0 but admittedly we could have done much better job with making it visible. We will pin this message in the first post too. |
|
|
|
We have but it is not yet ready for the public releases. User reported that 4.1a doesn't work with pool on etcget.net, but 4.0b was working fine. Could be same with other similar pools. Worth to inspect.
We have performed a quick test and there were no issues. Here is the command line we used: -pool stratum+tcp://eu.etcget.net:8018 -wal 0x008c26f3a2Ca8bdC11e5891e0278c9436B6F5d1E -worker Rig1 -pass x Same problem here , i have 2 rigs on a pool , but reported hashrate is only from the 1 rig ... i will go back to the previous version of PM
whalesburg miners reported some troubles with new version, sometimes miner restart or stuck
If the problems persists, please send us a (partial) log file to see what is going wrong. Unknown OpenCL driver version! Hashrate and stale shares may suffer OpenCL platform: OpenCL 2.1 AMD-APP (2766.4) Available GPUs for mining: GPU1: AMD Radeon (TM) RX 480 Graphics (pcie 1), OpenCL 1.2, 3.2 GB VRAM, 36 CUs GPU2: AMD Radeon (TM) RX 480 Graphics (pcie 3), OpenCL 1.2, 7.9 GB VRAM, 36 CUs GPU3: Radeon RX 580 Series (pcie 4), OpenCL 1.2, 8 GB VRAM, 36 CUs GPU4: Radeon RX 580 Series (pcie 6), OpenCL 1.2, 8 GB VRAM, 36 CUs GPU5: Radeon RX 580 Series (pcie  , OpenCL 1.2, 8 GB VRAM, 36 CUs im on ubuntu. i wonder witch is the know opencl driver ? Supported AMD Linux drivers are 16.40, 16.60, 17.10, 17.20, 17.30, 17.40, 17.50, 18.10, 18.20, 18.30, 18.40. The latest 18.50 drivers are not supported yet. what config do you guys use when you're trying to avoid screen lag?
I noticed that -mi set to lower than the default does not seem to affect screen lag and hashrate
so I'm still wondering which config should I change in case i want to use the computer while the miner is still running
I have set -mi to 12 when I'm not doing anything other than mining
Set -mi 0. If this is not enough, try -mi 8 -gpow 80 or -mi 8 -li 1 Increase/decrease the -gpow or -li values until you have smooth desktop experience without losing too much hashrate. |
|
|
|
The third beta of the new release is out (note that 4.1b wasn't released as we found some small bugs before it was out). You can download PhoenixMiner 4.1c from here: (MEGA links are no longer active) If you want to check the integrity of the downloaded file, please use the following hashes: File: PhoenixMiner_4.1c_Windows.zip
===================================
SHA-1: 695f269c335f7d525ecf96450702d643f15af98a
SHA-256: 93c3678a324fe677076cd746222dfec8e26be0fc758f0df080e14d6a5c8c4b91
SHA-512: 7c8544a3bfd367872b624b9e1bda12d1b5484a08d6e4d0a25abec2654242ceaf1df3a29fcd86e0a5bfd71927d1bda1ad716fc6d52a9cbddb714a8c521bb8db7b
File: PhoenixMiner_4.1c_Linux.tar.gz
====================================
SHA-1: 981dc17b1f51d56a1d025940c936a779f3be9198
SHA-256: 26d07ecb98c4d49205894224503a9faa4a1b5c5750875899cded22e5f2506815
SHA-512: c02c6baef626039de1070ca5e049c5a65986fa0e86ad64fdc019fe30599fd664238c20f1ab1cd7e3a68c82c9f54d16032a323e481018a0044881767104f44120
Here are the changes since 4.1a (the first beta of 4.1): - Added support for turbo kernels (-clkernel 3) and dual mining
- Added command-line option -vs to just print the version (e.g. 4.1c) and exit
- Added command-line option -wdtimeout to set the timeout of the watchdog timer. The valid values are from 30 to 300 seconds, the default is 45 seconds.
- Added support for Windows AMD drivers 19.1.1
- Small bugfixes
Here are the changes since 4.0b (the previous stable release): - Added faster "turbo" kernels (-clkernel 3) for AMD 470/480/570/580 GPUs. These are usually faster than normal kernels (-clkernel 1 or -clkernel 2) but require double the amount of VRAM. This means that you can only use them on 8 GB cards if mining ETH or ETC. You can use them on cards with 4 GB or less VRAM only if you are mining low DAG epoch coins.
- Added Blake2s dual mining kernels, and green kernels for AMD Fury GPUs
- Added Blake2s dual mining kernels for AMD 280/285/290/380/390 GPUs
- New faster kernels for AMD 280/290/390 GPUs
- Added alternative kernels (-clkernel 2) for AMD 280 GPUs
- Added options -pauseat and -resumeat for scheduled pausing and resuming of the miner. Example: -resumeat 22:00 -pauseat 6:00 - the miner will mine only between 22:00 and 6:00. Example 2: -resumeat 22:00,12:00 -pauseat 6:00,16:00 - you can specify multiple pause and resume times.
- (Windows only) The miner now prevents the computer from sleeping if the mining is not paused, and wakes the computer when it must resume mining at the time specified with -resumeat command-line option. In combination with -pauseat and -resumeat options this allows you to mine only when the electricity rates are lower and to keep your rig(s) asleep the rest of the time.
- When the miner is paused for more than a few minutes, the pool is disconnected. The pool connection is restored when the mining is resumed.
- Added a watchdog protection against freezing of the network connection thread
- Automatic selection of compatible devfee coin if there isn't enough VRAM to mine ETH and the main coin can't be recognized or isn't supported for devfee
- Automatic switch to the next pool if the cards VRAM is not enough for the requited DAG epoch. This is especially useful if the pool is auto-switching the coins but your cards only support lower DAG epoch coins.
- Added a -rvram option to set the minimal reserved VRAM that can't be used for mining. The default values are 384 MB on Windows, and 128 MB on Linux. You can also set -rvram -1 if you want to turn off the protection against using too much VRAM.
- Added support for Windows AMD drivers 18.12.x
- Other small improvements and fixes
Finally, please note that the versions of PhoenixMiner before 4.0 only support DAG epoch up to 235. Currently ETC is above this, and ETH is going to be on epoch 236 very soon. If you want to continue to mine ETH and ETCH, you must upgrade to PhoenixMiner 4.x. |
|
|
|
Could you please add the resulting autotuning parameters to the API?
Thaaaaaaaaank you!
There will be substantial additions to the remote management API but not in this release. Still no overclock or voltage control on nvidia cards?
Ethos has been able to do this for a long time.
We are giving priority to any ideas to bring up the ROI of the mining but these will be implemented eventually. Please suppress the warning messages about invalid epools.txt when valid epool parameters are passed via command line. Eth: Invalid wallet 'YourWallet.BLACKBOX' specified for pool 1 from epools.txt. Replace with a real wallet Eth: Invalid wallet 'YourWallet.BLACKBOX' specified for pool 2 from epools.txt. Replace with a real wallet # The pools specified in this file will be added to the pools specified with the PhoenixMiner's
# command-line options (see -pool and -pool2 command line options). When -epool -or -dpool is present, then no other pools should be used. This would change the way the miner behaved in all current releases, which will definitely cause problems for many users. You can either rename the epools.txt to something else, or comment out all lines there with the # character at the start of each line. turbo kernel error clCreateKernel (-46): Phoenix Miner 4.1a Windows/msvc - Release build
-----------------------------------------------
CUDA version: 10.0, CUDA runtime: 8.0
OpenCL driver version: 18.12.2,
Available GPUs for mining:
GPU1: Radeon RX 570 Series (pcie 8), OpenCL 2.0, 4 GB VRAM, 32 CUs
^C
c:\Users\Stephan\Desktop\MultiPoolMiner-Test\Bin\AMD_NVIDIA-PhoenixminerEthash_v4.1a>PhoenixMiner.exe -mport -4004 -proto 1 -pool europe.ethash-hub.miningpoolhub.com:20565 -wal ***************** -pass x -dcoin blake2s -dpool blake2s.eu.nicehash.com:3361 -dwal *************************.multipoolminer -dpass x -sci 60 -gt 0 -log 0 -wdog 0 -clkernel 3 -gpus 3
Phoenix Miner 4.1a Windows/msvc - Release build
-----------------------------------------------
CUDA version: 10.0, CUDA runtime: 8.0
OpenCL driver version: 18.12.2,
Available GPUs for mining:
GPU1: Radeon RX 570 Series (pcie 8), OpenCL 2.0, 4 GB VRAM, 32 CUs
...
Light cache generated in 0.9 s (26.0 MB/s)
GPU1: Allocating DAG (2x 1.44) GB; good for epoch up to #56
GPU1: Generating DAG for epoch #54
GPU1: DAG 50%
GPU1: DAG 100%
GPU1: DAG generated in 3.2 s (452.0 MB/s)
GPU1: Unable to prepare kernels: clCreateKernel (-46) Card is a RX 570 4 GB model. Should this not be enough memory? Thank you for reporting this. The -clkernel 3 option doesn't work with dual mining yet. We will try to include the turbo dual mining kernels in the final 4.1 release. any plans for kernal 3 for fury x or vega 64?
also the setting of etth (claymore lower limti of 50 being lowered to 25?) i think can help squeeze out some more hashs..
thanks
Unfortunately the techniques that make -clkernel 3 faster doesn't work on Fury and Vega GPUs. Can you please clarify what do you mean by etth? |
|
|
|
will you have support for ProgPoW?
Yes, absolutely. We will be ready for the future switch to ProgPow. Need to enable the user to increase the check interval for -wdog, for example -wdogtime 90. Now it costs 30 seconds, sometimes it’s not enough
We will add a similar option in 4.1b, which will be released in a few days. It should be noted that in this mode -clkernel 3, with the default setting -rvram video cards consume more power on average 2-4% and there will be more virtual memory loading, so maybe someone will need to increase it
Yes, depending on your overclocking settings the turbo kernels may consume more power. Also, you must re-run auto-tuning because the optimal -gt values will most likely be quite different for the new kernels. Note that you must also re-run auto-tune if you have AMD 280/285/290/380/390 GPU, because of updated kernels for these GPUs. |
|
|
|
The first beta of the 4.1 is ready. You can download PhoenixMiner 4.1a from here: (MEGA links are no longer active) If you want to check the integrity of the downloaded file, please use the following hashes: File: PhoenixMiner_4.1a_Windows.zip
===================================
SHA-1: 4ffa1fb84c351cd040386120f1b40f1724fdb3ab
SHA-256: 9940a8644293a73aa2d4f75152a3a5fde95610d2d168bcf882aff6f06af4beeb
SHA-512: fc34724cf4b841c145f04e0fdc59df6261fa715466ccdb1f430a2ca7584b7ab2da0e24b3832815f813dbbc27dc5c517b3c315897d420c2d0644f02b54236ee45
File: PhoenixMiner_4.1a_Linux.tar.gz
====================================
SHA-1: e5d265ee97000e4e231d8c5af3ebbc2d5abeb9bc
SHA-256: 8875882c2ff7714eafd26c11aa68115ff453159b2a3ca8464469dd3c1f7c3b22
SHA-512: f2527a598bb2875c127331a785c91907dc2b3eadd1115308c0ad42f762f9c8adc06b87934f0488fb337354b47b43df60c630478555508590182c4916d87d237e
Here are the release notes for this release: - Added faster "turbo" kernels (-clkernel 3) for AMD 470/480/570/580 GPUs. These are usually faster than normal kernels (-clkernel 1 or -clkernel 2) but require double the amount of VRAM. This means that you can only use them on 8 GB cards if mining ETH or ETC. You can use them on cards with 4 GB or less VRAM only if you are mining low DAG epoch coins.
- Added Blake2s dual mining kernels, and green kernels for AMD Fury GPUs
- Added Blake2s dual mining kernels for AMD 280/285/290/380/390 GPUs
- New faster kernels for AMD 280/290/390 GPUs
- Added alternative kernels (-clkernel 2) for AMD 280 GPUs
- Added options -pauseat and -resumeat for scheduled pausing and resuming of the miner. Example: -resumeat 22:00 -pauseat 6:00 - the miner will mine only between 22:00 and 6:00. Example 2: -resumeat 22:00,12:00 -pauseat 6:00,16:00 - you can specify multiple pause and resume times.
- (Windows only) The miner now prevents the computer from sleeping if the mining is not paused, and wakes the computer when it must resume mining at the time specified with -resumeat command-line option. In combination with -pauseat and -resumeat options this allows you to mine only when the electricity rates are lower and to keep your rig(s) asleep the rest of the time.
- When the miner is paused for more than a few minutes, the pool is disconnected. The pool connection is restored when the mining is resumed.
- Added a watchdog protection against freezing of the network connection thread
- Automatic selection of compatible devfee coin if there isn't enough VRAM to mine ETH and the main coin can't be recognized or isn't supported for devfee
- Automatic switch to the next pool if the cards VRAM is not enough for the requited DAG epoch. This is especially useful if the pool is auto-switching the coins but your cards only support lower DAG epoch coins.
- Added a -rvram option to set the minimal reserved VRAM that can't be used for mining. The default values are 384 MB on Windows, and 128 MB on Linux. You can also set -rvram -1 if you want to turn off the protection against using too much VRAM.
- Added support for Windows AMD drivers 18.12.x
- Other small improvements and fixes
|
|
|
|
So it's not possible to set -coin for devfee other that is mined?
I can't mine YOC and set "-coin ella" for dev fee?
No, it is absolutely possible to mine YOC and set ella for devfee coin, but you have to do it in the epools.txt if your pools are specified in epools.txt. Also, in such case you are better off selecting a DBIX (add -coin dbix in the command-line/config.txt, and COIN: dbix in the epools.txt) for example because it is only at DAG epoch 17 and has much smaller DAG than Ella (DAG epoch 95): POOL: YourYOCPool, WALLET: MyWallet, WORKER: MyWorkerName, PSW: x, COIN: dbix Just build a six GPU rig.
But when I run start.bat
The program try s to load 12 gpu's.
And then shuts down, because of the pagefile.
You have two sets of OpenCL drivers (one remaining from pre-18.10 drivers, and other from the 18.10, 18.11, or 18.12 drivers). The proper way to fix this is to use DDU to remove all AMD drivers then install the preferred driver. The quick and dirty way is to add -gpus 2,4,6,8,10,12 to your command line and ignore the "ghosts" of your cards. |
|
|
|
Added Extra config arguments: -coin ella But it not helped... Miner still trying to switch to ethereum for dev fee: GPU1: Allocating DAG (2.80) GB; good for epoch up to #230
GPU1: Allocating buffers failed with: clCreateBuffer (-61). The -coin command line option affects only the pool that is specified by -pool in the command line or in the config.txt file. For the pools in epools.txt, you have to specify the coin for each pool (usually PhoenixMiner is pretty good at detecting the current coin but since it fails in your case you must do it). In hiveos there usually is a template epools.txt file, where you should add the COIN: parameter: POOL: pool.ellaism.org:8008, WALLET: MyWallet, WORKER: MyWorkerName, PSW: x, COIN: ella If you have successfully set the coin parameter for the pool, you should see "Mining ELLA on ...." (the host address of the pool) message on the PhoenixMiner console. If the problem persists, please let us know which Ella pool you are using as we have tested with all major Ella pools and the coin auto-detection seems to work fine. nice dirty way , -gpus 2468 worked There may be a problem for using this way ? and , thanks PhoenixMiner is the best :X  No problem as it seems that both drivers are properly recognized. If one of them wasn't not recognized, you would get a yellow warning message about it in the first 30 seconds after starting the miner and your hashrate/stability may suffer. can you tell me .. its better have amd driver with open CL 2.1 ? or 2.0 ? thanks
There is no difference as far as mining goes. |
|
|
|
I have 4 GPU but in 4.0b it's show 8 GPU :| after few sec it be close automatically 2018.12.10:10:45:57.670: main No CUDA driver found
2018.12.10:10:45:59.996: main OpenCL driver version: 18.10/11
2018.12.10:10:45:59.996: main OpenCL driver version: 18.8/9
2018.12.10:10:45:59.996: main Available GPUs for mining:
2018.12.10:10:45:59.996: main GPU1: Radeon RX 580 Series (pcie 1), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.12.10:10:45:59.996: main GPU2: Radeon RX 580 Series (pcie 1), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.12.10:10:45:59.996: main GPU3: Radeon RX 580 Series (pcie 3), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.12.10:10:45:59.996: main GPU4: Radeon RX 580 Series (pcie 3), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.12.10:10:45:59.996: main GPU5: Radeon RX 580 Series (pcie 5), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.12.10:10:45:59.996: main GPU6: Radeon RX 580 Series (pcie 5), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.12.10:10:45:59.996: main GPU7: Radeon RX 580 Series (pcie 6), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.12.10:10:45:59.996: main GPU8: Radeon RX 580 Series (pcie 6), OpenCL 2.0, 8 GB VRAM, 36 CUs
2018.12.10:10:46:00.015: main ADL library initialized You have two different versions of the OpenCL driver (the old version wasn't uninstalled properly). The proper way to fix this is to use DDU to remove all AMD drivers then install the preferred driver. The quick and dirty way is to add -gpus 2468 to your command line and ignore the "ghosts" of your cards. Hello, I'm using the Phoenixminer for about a week now. The miner runs clean through 24/7. To this day, he had only worked for Devfee. Luckily I noticed this after 30 minutes and restarted Phoenix. How can I avoid this?
Thank you for the log! It appears that the stratum thread is freezing and your rig isn't sending any shares. This isn't related to devfee - the problem started before that and the devfee can't actually start (it is receiving jobs but can't send them to the GPUs) because the other thread did not release the GPUs. We will add code to detect similar problems and restart the rig to avoid useless mining without sending any of the found shares. Hi Phoenix! I have rig 4*GTX 1060 6GB nvidia drivers 399.07 winddows 7. Few daws I have problem to mine ETC with phoenix miner 3.5d. It can not mine ETC. With Claymore 11.8 and the same drivers - no any problem. Phoenix 3.5d on eth still works normally. 2018.12.11:01:41:28.669: main No OpenCL platforms found
2018.12.11:01:41:28.669: main Available GPUs for mining:
2018.12.11:01:41:28.669: main GPU1: GeForce GTX 1060 6GB (pcie 1), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2018.12.11:01:41:28.669: main GPU2: GeForce GTX 1060 6GB (pcie 4), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2018.12.11:01:41:28.669: main GPU3: GeForce GTX 1060 6GB (pcie 5), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2018.12.11:01:41:28.669: main GPU4: GeForce GTX 1060 6GB (pcie 6), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
.... You must upgrade to PhoenixMiner 4.0b because the older versions can't properly generate DAG epochs above 235 and currently the ETC is already on DAG epoch 236. You aren't facing the problem yet with ETH because it is on lower DAG epoch. |
|
|
|
I tried the new beta version, and I still got the "CudaProgram.cu:407 : out of memory " with my 1060 3gb cards if I start ETC mining. You have to use Windows 7 or Linux to mine ETC (and soon ETH) with 1060 3GB as Windows 10 "steals" part of the video RAM, making the allocation of enough memory for the DAG impossible even though the DAG is still way less than 3 GB.
Under Win7 is the same problem :/ We have a Win7 test rig with four GTX1060 3 GB and unfortunately it can't mine ETC since epoch 235. It still can mine ETH. Here are the things to look out for if you want to use it for as long as possible: - Add -eres 0 to the command line or config.txt file to disable over-allocation of the DAG buffer - Disable Win7 updates - Open Control Panel, search for "Adjust the appearance and performance of Windows", then disable all the options in the "Visual effects" tab in the "Performance Options" window. This should lower the video memory usage a little If everything else fails, your can always mine a low DAG coins like UBQ, DBIX, etc (virtually anything else than ETC and ETH will be mineable for quite a long time with 3GB GPU). Claymore 11.9 can control OC on nvidia 10 series cards as well as AMD RX 580 cards w/o installing any 3rd party tools. Just bare factory device driver minimum installation (no wattman/afterburn is needed). It's running very stable for long time. Can PhoenixMiner do that?
Not yet but we are working on it. So im having some issues with the miner. Ive tried everything on my end, and cant get rid of the crashes. here's my system: Windows 10 home ASUS Z270-A-PRO G3930 Celeron 16gb of RAM 128gb SSD 1 Gigabyte vega 56 When I tried to start the miner originally I was getting a bunch of errors (namely the 1500C temp error and it would lock up the system and put all fans to max) so, i updated to the 4.0b build from 3.5. Initially the miner was showing 2 Vega GPU's (only 1 installed) and was trying to mine with both of them at the same time. One was around 21mh/s the other was about 8mh/s (non dual mining just trying eth.) To fix this I used the -gpus 1 to tell it just to use 1 GPU, that managed to get it working and mining at normal speed using 1 "card". But, after some random time, usually around an hour into mining, the miner stops hashing and doesnt spit out an error, eventually when you try to move the mouse or hit any key on the keyboard it locks up the system and the only option is to hard shutdown. So with this and some searching I tried many things, removing the OC settings in Wattman (same result), updating windows (same result), then I updated the driver to the newest beta one and that managed to get it to work with out crashing. Then I implemented dual mining and tested for a couple days with no issues, so then I ran xmr-stak to CPU mine, and tested for a couple days as well. After testing for a couple days I went on vacation, came back it ran fine even through multiple internet drops (typical cable internet issues that have since been fixed with hundreds of dollars of equipment lol) each time reconnecting and continuing to hash like it should. Yesterday, I received my order for some new noctua fans and I shut down the computer and installed the fans. upon rebooting I was getting the same eventual hang in the system. So I dug into windows update thinking it must have installed an update and was causing this issue. So I uninstalled the update that showed it installed yesterday (besides an adobe flash one as I didnt think that would affect this situation) and its still having the same result. I updated the GPU driver to the newest beta again and still the same issue. Ive since constrained windows update even more than I had it before, to try to prevent something like this in the future. So with both the 18.11.2 ( i think it was) and the newest 18.12.1.1 beta driver I get the same results. below is a snippet of the log when it failed, from what I can tell its not showing any errors. 2018.12.07:11:09:39.599: main *** 1:36 *** 12/7 11:09 **************************************
2018.12.07:11:09:39.599: main Eth: Mining ETH on naw-eth.hiveon.net:4444 for 1:36
2018.12.07:11:09:39.599: main Eth: Accepted shares 42 (0 stales), rejected shares 0 (0 stales)
2018.12.07:11:09:39.599: main Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
2018.12.07:11:09:39.599: main B2S: Accepted shares 114 (0 stales), rejected shares 0 (0 stales)
2018.12.07:11:09:39.599: main B2S: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
2018.12.07:11:09:39.599: main Eth: Maximum difficulty of found share: 37.8 GH (!)
2018.12.07:11:09:39.599: main Eth: Average speed (5 min): 37.595 MH/s
2018.12.07:11:09:39.599: main Eth: Effective speed: 29.10 MH/s; at pool: 29.10 MH/s
2018.12.07:11:09:39.599: main B2S: Average speed (5 min): 1127.842 MH/s
2018.12.07:11:09:39.599: main B2S: Effective speed: 1086.03 MH/s; at pool: 1086.03 MH/s
2018.12.07:11:09:39.599: main
2018.12.07:11:09:39.662: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","worker":"test","params":[]}
2018.12.07:11:09:39.762: eths Eth: Received: {"jsonrpc":"2.0","result":["0xe13a2a342758ec7cefd8f38301b96583af181a0a1e5283a6f963d97deb1f1715","0xd9fa539e539d09362305f037610448e954ff0c3ef9d32854040c1c0c8cfa45a7","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba"],"id":5}
2018.12.07:11:09:43.061: eths Eth: Received: { "id":0 , "jsonrpc":"2.0", "result": ["0x3d6aa7cbc4e584f537233d1e98c760608cdb90c4869d4e6d62dfa5a45b6495b5","0xd9fa539e539d09362305f037610448e954ff0c3ef9d32854040c1c0c8cfa45a7","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba"] }
2018.12.07:11:09:43.061: eths Eth: New job #3d6aa7cb from naw-eth.hiveon.net:4444; diff: 4000MH
2018.12.07:11:09:44.605: main Eth speed: 37.311 MH/s, shares: 42/0/0, time: 1:36
2018.12.07:11:09:44.605: main B2S speed: 1119.315 MH/s, shares: 114/0/0
2018.12.07:11:09:48.065: eths Eth: Received: { "id":0 , "jsonrpc":"2.0", "result": ["0xf779042bcafe4f48beb5364925785e556fcbf274d32c679127fc476e7b5b355c","0xd9fa539e539d09362305f037610448e954ff0c3ef9d32854040c1c0c8cfa45a7","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba"] }
2018.12.07:11:09:48.065: eths Eth: New job #f779042b from naw-eth.hiveon.net:4444; diff: 4000MH
2018.12.07:11:09:49.804: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:36
2018.12.07:11:09:49.804: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:09:54.830: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:36
2018.12.07:11:09:54.830: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:09:59.973: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:36
2018.12.07:11:09:59.973: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:01.017: duas B2S: Received: {"id":null,"method":"mining.notify","params":["5e1","d020859b8e0ebb0954b3b49511fb9419e0237444297a183bc625eb89630b3d9d","0200000040b60a5c010000000000000000000000000000000000000000000000000000000000000000ffffffff1f03f88229062f503253482f0478b70a5c08","7969696d700000000000012071842b000000002321037670d24409d242e8dd518bf6aaab36162c8536a3e8789892d7db79cf401ca3e1ac00000000",["8ecd9e09f8831e65d1e6f5f19acc409bdb057bbb3f8304e902a6eb6f527b5d7f"],"00002004","1a03628a","5c0ab640",true]}
2018.12.07:11:10:05.180: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:36
2018.12.07:11:10:05.180: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:10.212: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:36
2018.12.07:11:10:10.212: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:15.215: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:36
2018.12.07:11:10:15.215: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:20.291: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:36
2018.12.07:11:10:20.291: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:24.689: main
2018.12.07:11:10:24.689: main *** 1:36 *** 12/7 11:10 **************************************
2018.12.07:11:10:24.689: main Eth: Mining ETH on naw-eth.hiveon.net:4444 for 1:36
2018.12.07:11:10:24.689: main Eth: Accepted shares 42 (0 stales), rejected shares 0 (0 stales)
2018.12.07:11:10:24.689: main Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
2018.12.07:11:10:24.689: main B2S: Accepted shares 114 (0 stales), rejected shares 0 (0 stales)
2018.12.07:11:10:24.689: main B2S: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
2018.12.07:11:10:24.689: main Eth: Maximum difficulty of found share: 37.8 GH (!)
2018.12.07:11:10:24.689: main Eth: Average speed (5 min): 31.891 MH/s
2018.12.07:11:10:24.689: main Eth: Effective speed: 28.87 MH/s; at pool: 28.87 MH/s
2018.12.07:11:10:24.689: main B2S: Average speed (5 min): 956.723 MH/s
2018.12.07:11:10:24.689: main B2S: Effective speed: 1077.63 MH/s; at pool: 1077.63 MH/s
2018.12.07:11:10:24.689: main
2018.12.07:11:10:25.363: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:37
2018.12.07:11:10:25.363: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:30.476: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:37
2018.12.07:11:10:30.476: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:35.682: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:37
2018.12.07:11:10:35.682: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:40.724: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:37
2018.12.07:11:10:40.724: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:45.930: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:37
2018.12.07:11:10:45.930: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:50.989: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:37
2018.12.07:11:10:50.989: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:10:56.181: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:37
2018.12.07:11:10:56.181: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:11:01.420: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:37
2018.12.07:11:11:01.420: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:11:05.395: wdog GPU1 not responding
2018.12.07:11:11:05.395: wdog Thread(s) not responding. Restarting.
2018.12.07:11:11:06.630: main Eth speed: 0.000 MH/s, shares: 42/0/0, time: 1:37
2018.12.07:11:11:06.630: main B2S speed: 0.000 MH/s, shares: 114/0/0
2018.12.07:11:11:09.812: main
2018.12.07:11:11:09.812: main *** 1:37 *** 12/7 11:11 **************************************
2018.12.07:11:11:09.812: main Eth: Mining ETH on naw-eth.hiveon.net:4444 for 1:37
2018.12.07:11:11:09.812: main Eth: Accepted shares 42 (0 stales), rejected shares 0 (0 stales)
2018.12.07:11:11:09.812: main Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
2018.12.07:11:11:09.812: main B2S: Accepted shares 114 (0 stales), rejected shares 0 (0 stales)
2018.12.07:11:11:09.812: main B2S: Incorrect shares 0 (0.00%), est. stales percentage 0.00%
2018.12.07:11:11:09.812: main Eth: Maximum difficulty of found share: 37.8 GH (!)
2018.12.07:11:11:09.812: main Eth: Average speed (5 min): 26.163 MH/s
2018.12.07:11:11:09.812: main Eth: Effective speed: 28.65 MH/s; at pool: 28.65 MH/s
2018.12.07:11:11:09.812: main B2S: Average speed (5 min): 784.903 MH/s
2018.12.07:11:11:09.812: main B2S: Effective speed: 1069.36 MH/s; at pool: 1069.36 MH/s
2018.12.07:11:11:09.812: main If anyone has any trick or tips to get this issue fixed please let me know, I would love to get back the random stability that I had for that short time. (Oh and thank you Phoenix crew for getting the Nvidia DAG issue resolved! I was finally able to use my Nvidia rig and tested it for 3 days with no issues!) Thank you all for any help you can provide. So after messing with it so much and it hanging in the middle of i guess an update install it destroyed my win install so i went ahead and upgraded to my new drive and installed windows 10 pro fresh. everything was good for about 3 hours then it locked up which is the longest ive been able to get it to run besides the one 12 day period randomly. We have one Gigabyte Vega 56 and it is a real PITA as far as stability goes, even without any overclock. Basically, the problem is probably related to overheating HBM. Make sure that the temperature limit of the card is set very low (e.g. no more than 60 degrees C) because the memory will almost always be much hotter. Also the fan must be allowed go at least to 60% and you must make sure that there is relatively cool airflow for the card (i.e. don't put it in the middle where it sucks hot air from the other cards). Note that this is not Vega problem but Gigabyte problem - we have two other Vega cards from PowerColor and they work fine without any stability issues. 2018.12.08:02:23:40.345: main Phoenix Miner 4.0b Windows/msvc - Release build
2018.12.08:02:23:40.345: main No CUDA driver found
2018.12.08:02:23:42.121: main OpenCL driver version: 17.8-BETA
2018.12.08:02:23:42.121: main Available GPUs for mining:
2018.12.08:02:23:42.121: main GPU1: Radeon RX 580 Series (pcie 1), OpenCL 1.2, 3 GB VRAM, 36 CUs
2018.12.08:02:23:42.121: main GPU2: Radeon RX 580 Series (pcie 3), OpenCL 1.2, 3 GB VRAM, 36 CUs
2018.12.08:02:23:42.121: main GPU3: Radeon RX 580 Series (pcie 4), OpenCL 1.2, 3 GB VRAM, 36 CUs
2018.12.08:02:23:42.121: main GPU4: Radeon RX 580 Series (pcie 6), OpenCL 1.2, 3 GB VRAM, 36 CUs
2018.12.08:02:23:42.121: main GPU5: Radeon RX 580 Series (pcie 8), OpenCL 1.2, 3 GB VRAM, 36 CUs
2018.12.08:02:23:43.710: main Starting GPU mining
2018.12.08:02:23:43.710: main Matched GPU1 to ADL adapter index 6 (method 1)
2018.12.08:02:23:43.737: main GPU1: Using the X2 ODN API
2018.12.08:02:23:43.737: main GPU1: Created ADL monitor for adapter 6; overdrive version: 7
2018.12.08:02:23:43.737: main GPU1: using the blockchain beta driver
2018.12.08:02:23:43.737: main Matched GPU2 to ADL adapter index 24 (method 1)
2018.12.08:02:23:43.763: main GPU2: Using the X2 ODN API
2018.12.08:02:23:43.763: main GPU2: Created ADL monitor for adapter 24; overdrive version: 7
2018.12.08:02:23:43.764: main GPU2: using the blockchain beta driver
2018.12.08:02:23:43.764: main Matched GPU3 to ADL adapter index 18 (method 1)
2018.12.08:02:23:43.792: main GPU3: Using the X2 ODN API
2018.12.08:02:23:43.792: main GPU3: Created ADL monitor for adapter 18; overdrive version: 7
2018.12.08:02:23:43.792: main GPU3: using the blockchain beta driver
2018.12.08:02:23:43.792: main Matched GPU4 to ADL adapter index 0 (method 1)
2018.12.08:02:23:43.820: main GPU4: Using the X2 ODN API
2018.12.08:02:23:43.820: main GPU4: Created ADL monitor for adapter 0; overdrive version: 7
2018.12.08:02:23:43.820: main GPU4: using the blockchain beta driver
2018.12.08:02:23:43.820: main Matched GPU5 to ADL adapter index 12 (method 1)
2018.12.08:02:23:43.848: main GPU5: Using the X2 ODN API
2018.12.08:02:23:43.848: main GPU5: Created ADL monitor for adapter 12; overdrive version: 7
2018.12.08:02:23:43.848: main GPU5: using the blockchain beta driver
2018.12.08:02:23:43.848: wdog Starting watchdog thread
2018.12.08:02:23:43.849: main Eth: Connecting to ethash pool us1.ethermine.org:4444 (proto: EthProxy)
2018.12.08:02:23:44.051: main Listening for CDM remote manager at port 3333 in read-only mode
2018.12.08:02:23:44.054: main GPU1: 28C 70%, GPU2: 26C 70%, GPU3: 28C 70%, GPU4: 27C 70%, GPU5: 28C 70%
2018.12.08:02:23:45.022: eths Eth: Connected to ethash pool us1.ethermine.org:4444 (172.65.218.238)
2018.12.08:02:23:45.214: eths Eth: Received: {"id":1,"jsonrpc":"2.0","result":true}
2018.12.08:02:23:45.214: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2018.12.08:02:23:45.368: eths Eth: Received: {"id":5,"jsonrpc":"2.0","result":["0x4f508231e87cdba2ccb108dd61fb36a8396f5c39f0f7235f9278355a4087e4fe","0xd9fa539e539d09362305f037610448e954ff0c3ef9d32854040c1c0c8cfa45a7","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x68757f"]}
2018.12.08:02:23:45.368: eths Eth: New job #4f508231 from us1.ethermine.org:4444; diff: 4000MH
2018.12.08:02:23:45.368: GPU1 GPU1: Starting up... (0)
2018.12.08:02:23:45.369: GPU1 GPU1: Generating ethash light cache for epoch #228
2018.12.08:02:23:45.370: GPU2 GPU2: Starting up... (0)
2018.12.08:02:23:45.372: GPU3 GPU3: Starting up... (0)
2018.12.08:02:23:45.374: GPU4 GPU4: Starting up... (0)
2018.12.08:02:23:45.376: GPU5 GPU5: Starting up... (0)
2018.12.08:02:23:48.578: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x562566f0f8be03dcf25ae394daa6f4ad1118b4b59c468ac6984c7bd03fd9149a","0xd9fa539e539d09362305f037610448e954ff0c3ef9d32854040c1c0c8cfa45a7","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x687580"]}
2018.12.08:02:23:48.578: eths Eth: New job #562566f0 from us1.ethermine.org:4444; diff: 4000MH
2018.12.08:02:23:48.874: GPU1 Light cache generated in 3.5 s (12.7 MB/s)
2018.12.08:02:23:48.929: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
2018.12.08:02:23:48.929: main GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0) 3: 0.000 MH/s (0) 4: 0.000 MH/s (0) 5: 0.000 MH/s (0)
2018.12.08:02:23:49.008: GPU1 GPU1: clCreateCommandQueue (-6)
2018.12.08:02:23:49.114: GPU3 GPU3: clCreateCommandQueue (-6)
2018.12.08:02:23:49.216: GPU4 GPU4: clCreateCommandQueue (-6)
2018.12.08:02:23:49.319: GPU5 GPU5: clCreateCommandQueue (-6)
2018.12.08:02:23:49.421: GPU2 GPU2: clCreateCommandQueue (-6)
2018.12.08:02:23:49.849: wdog Thread(s) not responding. Restarting.
2018.12.08:02:23:50.078: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0x0581642034553cd9947e039b68a21d84753436db76ee2f91866a9aee0ffc8865","0xd9fa539e539d09362305f037610448e954ff0c3ef9d32854040c1c0c8cfa45a7","0x0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x687581"]}
2018.12.08:02:23:50.078: eths Eth: New job #05816420 from us1.ethermine.org:4444; diff: 4000MH
2018.12.08:02:23:50.097: GPU1 GPU1: Starting up... (0)
2018.12.08:02:23:50.113: GPU2 GPU2: Starting up... (0)
2018.12.08:02:23:50.118: GPU3 GPU3: Starting up... (0)
2018.12.08:02:23:50.136: GPU4 GPU4: Starting up... (0)
2018.12.08:02:23:50.155: GPU5 GPU5: Starting up... (0) WINDOWS 10 Block chaindriver. Im having this problem run great with Claymore, but i want to use phoenix.. Definitely a driver issue. The cards are shown having 3 GB VRAM and only OpenCL 1.2 (they must show 4 GB VRAM and OpenCL 2.0). Still, before reinstalling the drivers, check the Task Manager to see if there is any running instance of PhoenixMiner or any other miner and if so, restart Windows. If this doesn't help, use DDU to remove the current drivers completely, then install them again (the blockchain drivers will do but obviously they are messed up somehow, so better use newer drivers, for example 18.5.1 and make sure that the Compute mode is turned on). Why only dual mining only AMD cards and not Nvidia cards PM dev??
We will be adding dual mining for Nvidia GPUs in the next version. |
|
|
|
Is correct to load two kernels? GPU5: Using Ethash OCL kernels (Ellesmere; -clkernel 1 -clgreen 1)
GPU9: DAG 63%
GPU3: DAG generated in 5.5 s (525.0 MB/s)
GPU3: Using Ethash OCL kernels (Ellesmere; -clkernel 1 -clgreen 1)
GPU2: DAG generated in 6.0 s (482.2 MB/s)
GPU2: Using Ethash OCL kernels (Ellesmere; -clkernel 1 -clgreen 1) I have entered only -clgreen kernel. Yes, this is correct and there is no error. This is just a new way to show you the kind of kernel each GPU is using by showing the relevant command-line options for this GPU (as some GPUs don't support -clkernel 2, others don't support -clgreen 1 kernels, etc). In the versions before 4.0 it was shown as "optimized green kernel". Having issues with UBQ-HASH and naming workers. If I put anything after my address example (a9224303048j9.RIG1) It will not connect to the pool (Ubiq.Hodlpool:8009). If I get rid of the rig name it will connect and hash fine (BTW 6-7Mh/s increase over UBQHASH ETHminer!)
Depending on the pool, you may have to use the -worker command line option (or WORKER: in the epools.txt). Some pools accept the worker name as part of the wallet but others require it to be separate. On behalf of the MaxHash Pools team and our Ubiq community, we would like to personally thank the Phoenix miner devs for incorporating Ubiq miner into the latest build.
Great job on giving miners another option and if you need any assistance/advice on Ubiq related matters then feel free to get in touch.
Big props!
-Team MaxHash
Thank you! We are glad to support Ubqhash as something like this is probably the way forward in the battle against ASIC miners. Thankfully the ubqhash didn't require huge changes in our code base, so it was done relatively quickly. ... - Finally, please note that the versions of PhoenixMiner before 4.0 only support DAG epoch up to 235. Currently ETC is on DAG 233, so in less than two weeks the old version of PhoenixMiner won't be able to create DAG or mine ETC - you have to upgrade to PhoenixMiner 4.0. For ETH there is more time as it is on DAG 225, and it won't be affected until the next year. As with ETC, you just need to upgrade to the latest version of PhoenixMiner in order to fix the problem.
I tried the new beta version, and I still got the "CudaProgram.cu:407 : out of memory " with my 1060 3gb cards if I start ETC mining. You have to use Windows 7 or Linux to mine ETC (and soon ETH) with 1060 3GB as Windows 10 "steals" part of the video RAM, making the allocation of enough memory for the DAG impossible even though the DAG is still way less than 3 GB. How will dual mining affect ETH hashrate and power usage?
Using radeon 570
I try with my 4x RX470, 600 W in solo, 705 W adding Blake2S from Nicehash, the hasrate drop from 29,8 MH/s per card to 28,2 Mh/s Does blake2s earnings cover the new power cost? For the most miners - no. However some may have access to very cheap or free electricity, or want to mine other coins for whatever reasons (want to support the blockchain, believe in the potential of said coin, etc), so there are reasons for dual mining, just not for most miners. Could You create dedicated thread in forum with first post always contain newer version od this miner? or github? ...like other miners does already (t-rex, z-enemy...., and almost all others). I wish to have easy way to automate check for new versions We only put a new release in the first post whenever it is deemed stable enough for wide release. Before that it is in "open" beta stage where everyone can try it but it is not recommended for wide deployment for example on big farms with a lot of rigs. |
|
|
|
|
As there are no major bugs or problems with PhoenixMiner 4.0b, it is promoted as the current stable release of PhoenixMiner. If you are already running PhoenixMiner 4.0b there is no need to download and install again - the files are binary identical to these published last week here.
|
|
|
|
This is my first time to use your miner after reading all the comments here, they got my interest in using your it, by the way is my command line is correct? I am using 12 rx 570 4gb in 1 rig.. with win10 18.6.1 radeon, all cards are moded. here's my command: PhoenixMiner.exe -pool mine.house:7007 -wal 0x3d046******** -pass x -clgreen 1 -fanmin 45 -fanmax 70 -worker ** -coin dbix -stales 0 -cdm 0 -amd -acm All of your help will be appreciated.. Thanks  Result: My rig crash every 3-5 mins running. The command line seems fine. As the crash happens after the mining has started perhaps the overclocking settings of the cards are too high. In the first few minutes the miner will perform auto-tune as there is not explicitly specified -gt parameter. You can try the following things to fix the problem: * Start the miner only with half GPUs (add -gpus 123456 to start with 6 GPUs only) and see if it still crashes. If not, wait until auto-tuning is over (it usually takes less than 5 minutes), press 's' on the miner console window and write down the -gt values (they should be fairly similar if the GPUs are the same). Then try to start the miner again with all GPUs but with added -gt parameter (e.g. -gt 45 if the best found -gt parameter was in 43-47 range for the individual GPUs). * Lower the memory clocks and/or increase the core voltage sligthly. * Try using the non-green kernels (remove -clgreen 1) or try using the alternative kernels ( -clkernel 2) -proto 3 does not work with 4. starts with default proto setting.
alsos if press c on miner screen(reload config), it starts miner in dual mining mode. i haven't set up dual miner.
Thank you for reporting about the problem with the 'c' key. The message about switching to dual-mining mode is harmless but we fixed than anyway in 4.0b. -proto 3 works as before for us. Can you please send us a command-line example where it doesn't work? I'm using HIVE OS 0.6 now, all my AMD cards works like charm with Phoenix miner, but none of my Nvidia cards work with Phoenix Miner,
I tried parameters like:
-nvidia
-gser
-nvNew
-nvf
-coin
for sure I added 0 or 1 or value after them, but nothing works, cards can be initialized but no DAG log shows, hash rate stay at 0, nothing happened until miner restarted.
Can you please send us the log for the first 1-2 minutes? We are unable to reproduce this problem here. |
|
|
|
The second beta of the new release is out. You can download PhoenixMiner 4.0b from here: (MEGA links are no longer active) If you want to check the integrity of the downloaded file, please use the following hashes: File: PhoenixMiner_4.0b_Windows.zip
===================================
SHA-1: 09d6cd23b151519e90abd8c9fcecd92eddce65b5
SHA-256: b77ff5410e5b3f343900c4f2a52257e1836fb718d048f838b5b97235943b2ee0
SHA-512: edcc771c243e4797cb59e9da4c4a9fa229f39dfbae7a1f65c5927f58c93833cb85543d3ca5b122d69822fe3c66500a5dbe547f419faa6156edf5d12ef63b470e
File: PhoenixMiner_4.0b_Linux.tar.gz
====================================
SHA-1: 1cab40e019adb61a1d1a04761834451391e7c31b
SHA-256: 354307c366d32b37793022aced287f6a76dc1037e98ab18d1af400bc532ba0d2
SHA-512: 7f83459468662973a590a9d0d3722e1583d5c77de182be0601dd4c5ee009c870209a437c17819668b061d2f7cc28cc57726f4f47d2e87fe0f316b88a6c679c41
Here are the changes since 4.0a: * Added support for the new Ubqhash algorithm required for mining UBQ. Please note that you must add -coin ubq to your command line (or COIN: ubq to your epools.txt file) in order to mine UBQ * Some small bugfixes Here are the changes since 3.5d: * Implemented dual mining (Ethash/Blake2s) for some AMD GPUs (RX580/570/560/480/470/460 and Vega). Use the new -dpool, -dwal, -dpass, -dworker, and -dcoin options to set the Blake2s pool. You can set the secondary coin mining intensity with the -sci option. For more information see the Readme.txt file. Note that the devfee when using dual mining is 0.9% on the ethash coin (there is no devfee on the secondary coin). * New kernels for most AMD GPUs with better performance and hashrate stability (you may need to run auto-tune again to find the best GT values) * New kernels for Nvidia GPUs with slightly better hashrate * Stability improvements in the Linux version * Support for the latest Windows drivers for AMD GPUs (up to 18.11.2) * Many other small fixes and improvements Here is an example command-line to use dual-mining:* ETH on ethermine.org ETH, Blake2s on Nicehash: PhoenixMiner.exe -pool ssl://eu1.ethermine.org:5555 -pool2 ssl://us1.ethermine.org:5555 -wal YourEthWalletAddress.WorkerName -proto 3 -dpool blake2s.eu.nicehash.com:3361 -dwal YourBtcWalletAddress -dcoin blake2s * Nicehash (Ethash + Blake2s): PhoenixMiner.exe -pool stratum+tcp://daggerhashimoto.eu.nicehash.com:3353 -wal YourBtcWalletAddress -pass x -proto 4 -stales 0 -dpool blake2s.eu.nicehash.com:3361 -dwal YourBtcWalletAddress -dcoin blake2s * maxhash.org (UBIQ): PhoenixMiner.exe -pool ubiq-us.maxhash.org:10008 -wal YourUbqWalletAddress -worker WorkerName -coin ubq * ubiq.minerpool.net (UBIQ): PhoenixMiner.exe -pool lb.geo.ubiqpool.org:8001 -wal YourUbqWalletAddress -pass x -worker WorkerName -coin ubq * ubiqpool.io (UBIQ): PhoenixMiner.exe -pool eu2.ubiqpool.io:8008 -wal YourUbqWalletAddress.WorkerName -pass x -proto 4 -coin ubq Here are some notes on the 4.0 release (repeated from our post for 4.0a as they are relevant to 4.0b too): - The best -sci values may be found via auto-tuning similar to the best -gt values in the ethash-only mode. You can either press "z" in the miner's console when dual-mining, or specify -sci 0 at the command line to force auto tune in dual-mining mode. Note that the auto-tune will find the best -sci value with respect to the speed of the ethash algorithm, even if the speed of the Blake2s becomes too low as a result of that.
- We got a lot of requests for Ubqhash support and we are in the process of implementing it. However it seems that some of the pools are still a little buggy. The ubqhash support should be ready in a few days.
- Unfortunately, the hardware control improvements weren't ready for this release. 4.0a still only supports controlling the clocks/fans/temperatures only on AMD GPUs under Windows. We will try to finish the changes for the final 4.0 release in about two weeks but the improvements in the kernels were deemed more important. There is no change in the hardware control for Linux too - you still have to use third party application for this
- The dual mining for the rest of AMD cards, and for Nvidia cards in currently being implemented.
- Finally, please note that the versions of PhoenixMiner before 4.0 only support DAG epoch up to 235. Currently ETC is on DAG 233, so in less than two weeks the old version of PhoenixMiner won't be able to create DAG or mine ETC - you have to upgrade to PhoenixMiner 4.0. For ETH there is more time as it is on DAG 225, and it won't be affected until the next year. As with ETC, you just need to upgrade to the latest version of PhoenixMiner in order to fix the problem.
|
|
|
|
|
Show Posts
