Having problem with 1060 3gb and buffer (I have 25gb of pagefile). Im back to claymore (using -eres 0).
I will wait a fix in phoenix..
You can use -eres 0 with PhoenixMiner too. However this is only a temporary solution - in a few weeks you will have to switch to Windows 7 or other OS that doesn't hog the GPU memory like Windows 10 does. cvddc and mvddc do not work for AMD blockchain drivers 23 august 2017, claymore does, can you make it to work on your miner? Also, claymore stale shares are lower than your miner right now.
This is a known issue and unfortunately we can't lose more time trying to fix it as in these drivers the ADL support is seriously broken. The OC settings should work properly in any of the new 18.x.x drivers. As for the stale shares, this should be solved in the new PhoenixMiner 2.8b. ....
Thanks for responding, that info is helpful. I did actually notice that even on reboot, the hardware settings previously set in PM are still active. But, like I said, I've been shutting down with a taskkill. I will continue to experiment. Considering that you specify a voltage in mV and not a mV offset I could not figure out the problem I'm seeing with super low voltages. If I reset my GPU using MSI AB (I didn't know there was a -resetoc command) and I run PM with a undervolt, say 1050mV on the core. It goes off and voltage looks good. Then if I close (the wrong way, I know), the 1050mV core voltage persists, but I understand why now. What is still a mystery, is that when I launch PM again, with the same 1050mV setting in my bat, then I see like 930mV in GPU-Z and I get artifacts leading to either driver crash or BSOD. So I still can't figure that one out. Again, this is on an R9 390 / Hawaii.
Regardless, thanks for the great attentiveness to user issues!
There is no -resetoc option in the current release but it will be added in the final 2.8 (or in the first 2.9 if it prove challenging). We will investigate the issue further, using the same card as we were quite busy with the new AMD kernels. 2.8 crashes one of my rigs every 3-4 hours and needs manual intervention. Can’t really figure it out.
Could you send us a log file from around the crash? Also, info about what card you are using and which drivers would be helpful. Does the miner support Ethereum classic, can you provide list of supported coins?
Yes, it does. You can see the list of supported coins on the first page of this thread under the possible values of the -coin command line option: -coin <coin> Ethash coin to use for devfee to avoid switching DAGs:
auto: Try to determine from the pool address (default)
eth: Ethereum
etc: Ethereum Classic
exp: Expanse
music: Musicoin
ubq: UBIQ
pirl: Pirl
ella: Ellaism
etp: Metaverse ETP
pgc: Pegascoin
akroma: Akroma
whale: WhaleCoin
vic: Victorium |
|
|
|
Second beta of 2.8 is ready: PhoenixMiner 2.8b. It can be downloaded from here: (MEGA links are no longer active) Here are the checksums to verify the download: File: PhoenixMiner_2.8b.zip
SHA-1: 650c584763e99fb69599e7a7cf88523ffe8c3467
SHA-256: d7892cee8695595685e796c4f7513b31bfa71b2180885b5ea3630dca43496c85
SHA-512: 516ef2165d6170939b88d94a5f64764ffd861b9873c7ac1c80b0a7780c9af1ce22e96f6e50721c551a9434c9c4b7864d6a04cf7798a6452042db343064f8513d
Note that this is not an official release. The changes are: - New AMD kernels for AMD RX470/480/570/580, Vega, and Fury, providing slightly higher hashrate and slightly lower percentage of stale shares. The new kernels are used by default on these GPUs. You can also revert to using the old kernels with -clkernel 1 (or -clkernel 2 for Polaris)
- When using the new kernels, the mining intensity is 12 by default instead of 10
- The mining intensity range is now up to 14. Use the highest -mi values only with the new AMD kernels as for the other kernels the stale shares may increase too much
- Many small improvements and fixes
|
|
|
|
Hello Phoenixminer, when the new version? I have 2-5% stale shares and no improvement in the Kernel with rx580 8gb
2.8b will be released late Sunday or early Monday depending on stability during the internal tests. Rapidly switching between the 2 mining modes ("mine for yourself" and "mine for developers") puts rapidly changing workloads and heavy stress on GPU. It noticeably shortens the GPU's life and causes problems and weird breakdowns.
Also the switching causes a considerable loss of connection time, when it's not mining for anyone (neither for yourself nor for the developer). This lost time can even be longer than the time devoted to developer mining. The more frequent the switching is, the higher the loss. 90 minute period is quite frequent, do this 16 times a day and it easily wipes out any hash rate advantage.
There should be a better way to support the developers. A 1-time license payment is much better.
Or, change the switching period from 90 minutes to 12 hours. For every 12 hours the developers get 7 minutes of mining time. This way it not only reduces the switch from 16 times a day to twice, but the developers will also get a more consistent payment (mining is better done continuously for an unbroken period of time).
The way we have implemented the devfee switching in PhoenixMiner, there is no disruption in the GPU workload, nor any downtime at all. The switchover is absolutely transparent for the GPU and there is no lost hashrate. |
|
|
|
HI, is there an option to have my rig reboot i the speed drops below a set point?
I see that you can restart the miner but i want to restart the rig.
thanks, Robin
You can combine the -minRigSpeed option with -rmode 2. This will shut down the miner and execute the reboot.bat file, which must be provided by you with the necessary command(s) to restart the rig (e.g. shutdown /r /t 00). @PhoenixMiner
I really like the stability and the speed, here it comes, but,
The stale share rate is really bad.
I have all AMD cards, on another miner I get <1 % stale shares.
PhoenixMiner gets 5% to 10% stale shares.
This really needs to be looked at. The additional hash rate that I get using Phoenix is eaten up
with stale shares. I'm loosing .35% of 5 to 10% of all the shares submitted.
I know this can be solved, I've seen it solved elsewhere.
thanks
The new AMD kernels in 2.8b will address both the hashrate and the stale shares. Don't expect miracles but there will be tangible improvements in both areas. With that being said, we (or any other miner) can only lower the stale shares that are caused by the kernel latency (and this is the number reported by PhoenixMiner). It can't be 10% for a long period of time - the highest we have seen is 4% with -mi 12 and 2% with the default -mi 10. With the new kernels it will be at or below 1% with -mi 12. Is there a guide somewhere for exactly how the -gt option affects things? What does it make changes to, and to what degree?
Thanks for the work!
No guide, but it affects the rearrangement of instructions in attempt to hide the latency of the memory. You can try each value for a minute or so (until the hashrate stabilizes), then try with 10 more or less, and so on. Once you found the two best values, try each value between them to find the best one. It is kind of long process and should be repeated for each card unless they are identical and with the same overclocking settings and BIOS-es. Can you implement Claymore's auto tuning for best intensity per card?
We can implement something similar but only if it works more reliable. In our testing, Claymore's auto-tuning find the right -dcri option in his miner in only one from 10-15 attempts. With such success rate we feel that it is better to stick with the default value or tune manually. Ive been trying PM 2.7c on a standalone desktop with R9 390 8GB (XFX). I know this miner is focused on RX cards (which I have many of) but I have a fair number of R9 390s and I'm having a lot of hardware control problems.
I'm getting 'failure to set -tt error -1', but setting a static fan speed works. However, the fan speed sticks even after I close the miner. Similarly, my clocks and voltages will set (watching in GPU-Z), but they won't reset when the miner closes. This is a big problem since when I try to launch a second time, it seems like a negative voltage offset stacks with the first and I get BSOD, driver crash, etc. Regardless, I pretty much have to reboot to get it to start 'fresh'. It definitely seems faster when I can get it to run, but I have some machines that need to start and stop on demand.
MSI AB works for all my hardware settings, but I really would like the miner to handle it all and go back to stock settings when it stops. I have a few standalone desktops with one or two GPUs that I actually use and I like them to mine when idle (scheduled task) and stop when I sit down. I also have one dedicated rig that I run on a schedule to control heat midday. I've been running ethminer like this; scheduled task based on idle or time. I was about to jump to Claymore on my idle use machines simply because of the hardware control features (which ethminer lacks) so I don't have to keep switching MSI AB profiles, and that's when I discovered PhoenixMiner.
I'm just curious if these hardware control issues may be on my end or are a known issue with R9 series cards. I have tried 3 drivers in the 18 series, but I haven't gone back to 17. I've tried it with MSI AB reset to defaults, MSI AB completely uninstalled, AMD settings running and AMD settings not-running. I've lowered mining intensity and slowed DAG generation and all that, but the crashes really seem to be due to ridiculously low voltages on the second run of the miner, like PM is trying to stack a negative offset each time. Bottom line is PM doesn't release the hardware settings when it closes, at least it doesn't on this GPU and I feel like that's where my problems are coming from. I can run PM, close it, then run something like FurMark and all my clocks and voltages are still stuck on the PM settings.
I don't mean to sound high maintenance, just want to figure this out. If it's a known issue, hopefully it's one that will get fixed, but no big deal. Any input would be appreciated.
PhoenixMiner resets the OC settings if it is closed "gracefully" with Ctrl+C in the console (but not if it is closed by clicking the X button in the top right corner of the console). However, there is no definitive (i.e. fully documented) way to reset the OC settings, so it may not work with some cards (it does work with Polaris cards and 18.x.x drivers). Note that when we apply clocks and voltages, it is always with absolute values and not offsets. A possible workaround is to add command-line option -resetoc that will force PhoenixMiner to reset the OC settings at startup. We are also considering resetting the OC settings even when the miner is closed forcibly but this may cause problems if some of the GPUs are frozen and the miner is trying to restart. ...
@PhoenxiMiner
Please implement the auto tune feature in a release soon.
It's a big deal.
IF it works properly. And to do this, it must work much longer than 30 seconds (like at least 10 minutes). |
|
|
|
We will look into this and try fixing it for the 2.8b release. latest still wont attrack massive users until dual mining is implemented.
nonetheless, this is still the fastest and the most stable ethash miner.
if only dual wont benefit me much, ill transfer here.
We will implement dual mining eventually. On my RX 580 cards Claymore miner 11.5 still a bit faster. About 0,25-0,5%. His fee is 1%, Phoenix is 0,65. Result is no difference.
Phoenix gives much more rejected (staled) shares than Claymore's...
Continue to use Claymore...
Add an option like -ttli in Claymore. It enables low intensity mode on reaching pointed temperature...
There will be new experimental Ellesmere and Vega kernels in PhoenixMiner 2.8b. As for the -ttli option, in our experience the native GPU throttling works better: you just need to set -tmax (and -tstop with a few degrees higher temp) and the GPU should take care of throttling in a better way than it is possible by modulating the GPU usage via something like -ttli. - CPU utilization during normal operation is lowered by about a factor of 10 regardless of the number of GPUs
sounds familiar Well, we had to keep our advantage in this area  Hi Phoenix, great job on the miner, I've switched all my rigs completely to yours.
One quirk: I noticed your log is giving out a time that is one hour behind. For example, if it's 1:40pm in real time, the log will display current time as 12:40pm.
I'm based in Australia, where daylight savings is on currently. In about a couple weeks' time, our time will move 'behind' and essentially if the log does output the same time, the real time and log time will match.
Nonetheless, the problem still exists now. It's weird that the log is displaying 'timezone time disregarding daylight savings' instead of simply taking the computer's system time.
Could you please look into this? I have to manage 30+ rigs and little things like this can add up to a huge headache.
Thanks!
Sorry about that, we will fix it in 2.8b. Thanks phoenix for this good software, phoenixminer 2.8a has been stable for a while already, only hashrate on the pole measurement is less than what the phoenixminer indicates also the stale shares number does not match with the pool ethermine program gives 6 stale shares but on the pool ethermine it is 11 once phoenix does not know what you have done but the share number is much less than the phoenixminer version 2.6. I think the 2.6 version is the best in all fronts and More SHARES . What do the other users of this software actually think phoenixminer 2.6 or 2.8a. my rig is gtx 1060 6gb 6x. software windows 10 pro lite 64-bit- Nvidia driver 391.01 institution: 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 0xXXXXXXXXXXXXXXXX.rig4 -pass x -nvidia -proto 3 -ftimeout 120 -cdm 0 -mi 12 -log 0 -minRigSpeed 90.000 - rmode 2 -eres 0 -coin eth -coin2 eth The stale shares reported by PhoenixMiner will always be lower than the ones at the pool, as explained many times in this thread (and in the FAQ in the first post). The number of shares for a small period of time can vary wildly and is not a good indicator of the speed. Running 2.8a since yesterday evening, very stable even with my weakest GPU (lowest ASIC rate), same stale shares rate as 2.7C (2% the last hour).
I tried claymore V11.5 and got a hung GPU after 45mn (RX 570 4GB 1150MHz core / 2070MHz mem with bios mod), the same GPU can mine for hours and hours with phoenix.
Therefore I keep on using phoenixminer.
The new kernels for RX470/480/570/580 that are coming in 2.8b, should provide some speed increase as well, although their main goal is to increase stability and allow using higher mining intensity on the same voltages and clocks. on claymore i have "-eres 0" for error cuda, add on phoenix this command please!  This command exists in Phoenix miner. And it's the same as in Claymore. That is correct. However, -eres 0 is just a stopgap measure. After two more DAG epochs (i.e. in less than two weeks), the DAG memory problems will return again. The only real solution is to use either Windows 7 or some version of Windows, which doesn't hog GPU memory (some miners report good results with Windows Server 2016 but we can only confirm that Win 7 solves the problem for us). Changes in version 2.7c (since 2.6):
* Supports AMD Vega, 580/570/480/470, 460/560, Fury, 390/290 and older AMD GPUs with enough VRAM
sigh,,,,,, But it only supports compute 3.0 or higher Nvidia cards. Meanwhile ethminer, and other crypto apps support older Tesla cards from the c2050, m2050, and s2050 Fermi cored which haul ass still compared to some of the GTX series.. I have some 6GB and 3GB Teslas that still run well for CUDA 6.5 or higher. Why is it when developers crank out a new and improved version they kill off support for the hardware that got the game started a while ago? ccminer and a few others still have the source code or compiled archived versions out there. Is there a previous version of PhoenixMiner that will support the older Fermi based cards? The CUDA 9.1 dev kit can run on these cards. [/list] No, there never was any support for GPUs with less than CUDA cap 3.0 in PhoenixMiner. There are no fundamental problems to adapt the CUDA kernels for older GPUs, but we don't have any of them to test on and probably (like 99% probability) there will be bugs and crashes. Also, we use some features that were first introduced in 3.0, and while it is possible to provide versions that work with 2.0 and 2.1, they will be substantially slower and might not be able to mine enough coins to even pay the power bill. |
|
|
|
Luv this miner I find its giving me about 1 mh more than CL 10.4. I'm running several fury x and it seems there is room for more optimizations. if I can help in any way please pm me if I can provide you any data as id love to help you get these legacy cards more out of them for all fury users.
thanks
We definitely will not stop giving attention to the older GPUs because it seems that the advancements in this area are not forthcoming any time soon. is there any way to get fan control and overclocking for nvidia pascal cards? i'd love to get rid of using afterburner
Unlike the AMD's semi-document ADL interface, Nvidia is keeping their API close to the chest. We will try crack it the future but it is unknown how much time it would take and what would be the final functionality. Can anyone confirm DAG file limitations using 1060 3gb under windows 10 vs windows server?
I am unable to generate the DAG (epoch 176). I fresh installed windows 10 without any windows updates as well without a fix.
Anyone having similar problems or lack of problems running windows server 2016?
The only data point we can provide you is that under Windows 7, 1060 3GB has no problems mining even ETC right now. |
|
|
|
First beta version of 2.8 branch: PhoenixMiner 2.8a. It can be downloaded from here: (MEGA links are no longer active) Here are the checksums to verify the download: File: PhoenixMiner_2.8a.zip
SHA-1: 00fc3c698fadb7187632bf4e7ab9ecf0afd1c9a1
SHA-256: f3f4857ac85f31f2bee7a3d8b9c9c526c7dec0433c72b4c47555b47911323d00
SHA-512: f736bcd6a0c4b172f41452d8b1c324efc978540b5f4addc8a3387d23cb872538838bde0895f826649b5ba493bfd240b242edf0a91fc02d18d92fdc814ed7eac3
Note that this is not an official release. The changes are: - Small kernel stability improvements that also may (very) slightly increase the speed of Nvidia cards
- CPU utilization during normal operation is lowered by about a factor of 10 regardless of the number of GPUs
- Added support for -tstop and -tstart options to stop mining on given GPU if the temperature rise above specified value and restart it after it cools down below -tstart temperature
- Fixed the problem with console window freezing after scrolling
- Implemented new -gpow n option to lower the GPU utilization (the value n is the desired GPU utilization in percent; default: 100)
- Implemented the -li option to lower the intensity (use this instead of -gpow if you are already using -mi with low values)
- Improved GPU speed statistics, using moving average window for each GPU. You can change the size of the window with the -gswin n option (n is between 5-30 seconds; default 15; use 0 to revert to the old way of using 5 second "quants" which are independent of each other)
- You can now specify GPU number above 9 by typing three-digit sequence at the console (e.g. type 011 to pause or resume GPU11)
- Added support for the miner_getstat2 remote monitoring request
- Show the SSL and HTTP schemes to indicate the type of connection
- The command-line options are now case-insensitive
|
|
|
|
@PhoenixMiner, bro I have been with the newest version 2.7c for a week now and I see the following tendency - every 12 hours or so the rig freezes and stops mining, the cards go in idle state and I have to make a hard reset in order to restart the machine.
For the last 5 days this has happened around 5 times. What may be causing this issue? Anyone else with the same problem?
Obviously this is not DAG generation related as it happens too often, so we will need some logs to make any suggestions. When new version available? What are the best NVidia drivers/settings for the 1070 GPUs?
Regards
The first beta of 2.8 should be released tomorrow. We found some regressions during the internal testing and we had to delay the release. The -gt parameter is quite similar but not the same as -dcri. Replace -gt 110,44,110 with -dcri 110,44,110, which will force PhoenixMiner to try and approximate the GT values from the supplied -dcri values. Any reason this isn't mentioned in readme? Why hide such beneficial (albeit experimental) thing? Well, we print a warning for each Claymore command-line argument that is not implemented by us, and we assume that if anyone is switching over from Claymore, they would try first with the same command-line options as they used before. However, for the new users it is best to use directly the -gt parameter as the approximation of -dcri is not ideal and may give some strange results in certain cases. |
|
|
|
Tried to use phoenix miner for the first time today, got 0,00 MHS for some reason 17604:04:37:03.269: main Phoneix Miner 2.7c Windows/msvc - Release
17604:04:37:03.269: main Cmd line: -pool stratum+tcp://daggerhashimoto.eu.nicehash.com:3353 -wal nicehashwallet -pass x -proto 4 -stales 0 -amd
17604:04:37:03.950: main Available GPUs for mining:
17604:04:37:03.950: main GPU1: Radeon (TM) RX 480 Graphics (pcie 1), OpenCL 2.0, 8 GB VRAM, 36 CUs
17604:04:37:03.950: main GPU2: Radeon (TM) RX 480 Graphics (pcie 3), OpenCL 2.0, 8 GB VRAM, 36 CUs
17604:04:37:03.950: main GPU3: Radeon (TM) RX 480 Graphics (pcie 5), OpenCL 2.0, 8 GB VRAM, 36 CUs
17604:04:37:03.950: main GPU4: Radeon (TM) RX 480 Graphics (pcie 6), OpenCL 2.0, 8 GB VRAM, 36 CUs
17604:04:37:03.950: main GPU5: Radeon (TM) RX 480 Graphics (pcie 7), OpenCL 2.0, 8 GB VRAM, 36 CUs
17604:04:37:03.950: main GPU6: Radeon (TM) RX 480 Graphics (pcie 8), OpenCL 2.0, 8 GB VRAM, 36 CUs
17604:04:37:03.979: main ADL library initialized
17604:04:37:04.269: main Listening for CDM remote manager at port 3333 in read-only mode
17604:04:37:04.269: main Eth: the pool list contains 2 pools
17604:04:37:04.269: main Eth: primary pool: daggerhashimoto.eu.nicehash.com:3353
17604:04:37:04.269: main Starting GPU mining
17604:04:37:04.269: main Matched GPU1 to ADL adapter index 24 (method 1)
17604:04:37:04.299: main GPU1: Using the X2 ODN API
17604:04:37:04.299: main GPU1: Created ADL monitor for adapter 24; overdrive version: 7
17604:04:37:04.299: main Matched GPU2 to ADL adapter index 12 (method 1)
17604:04:37:04.329: main GPU2: Using the X2 ODN API
17604:04:37:04.329: main GPU2: Created ADL monitor for adapter 12; overdrive version: 7
17604:04:37:04.330: main Matched GPU3 to ADL adapter index 30 (method 1)
17604:04:37:04.360: main GPU3: Using the X2 ODN API
17604:04:37:04.360: main GPU3: Created ADL monitor for adapter 30; overdrive version: 7
17604:04:37:04.360: main Matched GPU4 to ADL adapter index 0 (method 1)
17604:04:37:04.390: main GPU4: Using the X2 ODN API
17604:04:37:04.390: main GPU4: Created ADL monitor for adapter 0; overdrive version: 7
17604:04:37:04.390: main Matched GPU5 to ADL adapter index 18 (method 1)
17604:04:37:04.421: main GPU5: Using the X2 ODN API
17604:04:37:04.421: main GPU5: Created ADL monitor for adapter 18; overdrive version: 7
17604:04:37:04.421: main Matched GPU6 to ADL adapter index 6 (method 1)
17604:04:37:04.454: main GPU6: Using the X2 ODN API
17604:04:37:04.454: main GPU6: Created ADL monitor for adapter 6; overdrive version: 7
17604:04:37:04.454: wdog Starting watchdog thread
17604:04:37:04.454: main Eth: Connecting to ethash pool daggerhashimoto.eu.nicehash.com:3353 (proto: Nicehash)
17604:04:37:04.495: eths Eth: Connected to ethash pool daggerhashimoto.eu.nicehash.com:3353 (159.122.29.199)
17604:04:37:04.495: eths Eth: Send: {"id":1,"method":"mining.subscribe","params":["PhoenixMiner/2.7c","EthereumStratum/1.0.0"]}
17604:04:37:04.566: eths Eth: Received: {"id":1,"error":null,"result":[["mining.notify","1b823da44765203241b8224983007c12","EthereumStratum/1.0.0"],"4b61a2"]}
17604:04:37:04.566: eths Eth: Extranonce set to 4b61a2
17604:04:37:04.566: eths Eth: Subscribed to ethash pool
17604:04:37:04.566: eths Eth: Send: {"id":2,"method":"mining.extranonce.subscribe","params":[]}
{"id":3,"method":"mining.authorize","params":["3C6VmPEhFSM7cj4aw89NhpZGmSovKffKVH","x"]}
17604:04:37:04.613: eths Eth: Received: {"id":3,"result":true,"error":null}
17604:04:37:04.613: eths Eth: Worker 3C6VmPEhFSM7cj4aw89NhpZGmSovKffKVH authorized
17604:04:37:04.631: eths Eth: Received: {"id":null,"method":"mining.set_difficulty","params":[0.5]}
17604:04:37:04.631: eths Eth: Difficulty set to 0.5
17604:04:37:04.631: eths Eth: Received: {"params":["000000251564b3f1","08e704bf06ac983d776d734cacf1f611802b802efb5a5f5cb8086d6a0d966ac5","ead2f865f18fd460b8938e49795e17d876b1cec5cda5ebc65b5381c46645ef18",true],"id":null,"method":"mining.notify"}
17604:04:37:04.631: eths Eth: New job #ead2f865 from daggerhashimoto.eu.nicehash.com:3353; diff: 2147MH
17604:04:37:04.631: GPU1 GPU1: Starting up... (0)
17604:04:37:04.631: GPU1 Eth: Generating light cache for epoch #175
17604:04:37:04.631: GPU2 GPU2: Starting up... (0)
17604:04:37:04.633: GPU3 GPU3: Starting up... (0)
17604:04:37:04.635: GPU4 GPU4: Starting up... (0)
17604:04:37:04.637: GPU5 GPU5: Starting up... (0)
17604:04:37:04.639: GPU6 GPU6: Starting up... (0)
17604:04:37:04.641: eths Eth: Received: {"id":2,"result":true,"error":null}
17604:04:37:04.659: main GPU1: 32C 0%, GPU2: 24C 70%, GPU3: 23C 75%, GPU4: 20C 75%, GPU5: 26C 95%, GPU6: 36C 60%
17604:04:37:07.205: GPU2 GPU2: Using optimized OpenCL kernels (device name 'Ellesmere')
17604:04:37:09.590: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
[b]17604:04:37:09.590: 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) 6: 0.000 MH/s (0)
17604:04:37:14.714: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
17604:04:37:14.714: 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) 6: 0.000 MH/s (0)
17604:04:37:19.862: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
17604:04:37:19.862: 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) 6: 0.000 MH/s (0)
17604:04:37:25.029: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
17604:04:37:25.029: 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) 6: 0.000 MH/s (0)
17604:04:37:30.157: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
17604:04:37:30.157: 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) 6: 0.000 MH/s (0)[/b]
17604:04:37:32.720: main GPU1: 32C 0%, GPU2: 25C 70%, GPU3: 23C 75%, GPU4: 21C 75%, GPU5: 26C 95%, GPU6: 37C 60% any ideas appreciated! The light cache generation on your rig is rather slow - it starts on 04:37:04.631 but it is still going on at 04:37:32, which is almost 30 seconds. Even on quite slow CPU (Athlon II X2, Celereon, etc.), this shouldn't take more than 10-15 seconds. Note that the light cache must be generated first before the DAGs are generated and then the mining will start. Check with Task Manager what is your CPU load, it is probably 100% for some reason. Even so, the light cache will be generated eventually but it may take a long time (e.g. minutes) if your CPU is 100% loaded with other higher-priority tasks. I Just switched to Phoenix. Performance is roughly the same as Claymore's, lower dev fee, it's a no brainer.
Dual mining is overrated as usual, unless you have free electricity.
Just one question: I had to set mining intensity to 12 to get same performance as Claymore's 11.4, no problem, power consumption is the same and all seems stable. But how about -dcri? C's 11.4 actually improved performance a bit by auto setting dcri in Eth only mode. I got -dcri 110,44,110.
Tried to use those values with -gt parameter in Phoenix bat file, but performance was much lower.
The -gt parameter is quite similar but not the same as -dcri. Replace -gt 110,44,110 with -dcri 110,44,110, which will force PhoenixMiner to try and approximate the GT values from the supplied -dcri values. a few hours back pool shows that rig went offline but the miner still submit shares.
i've restarted the miner and still submit shares as usual but pool still doesn't show that.
been in touch with ethermine support but they insist that it wasn't a server side fault. still not sure if it was a pool or miner issue but till then, i'll continue using claymore.
This sounds like the infamous MITM attack. Check the difficulty which is displayed each time when the miner receives a new job. On ethermine it is 4000MH but if your connection was hijacked it would be 10000MH. To prevent such attacks, use the SSL ports on ethermine and don't forget to add the ssl:// prefix too, like this: -pool ssl://eu1.ethermine.org:5555 -pool2 ssl://us1.ethermine.org:5555Phoenix 2.7c crashes with the settings I have and with so many GPU's it will take lot of time to re-tune the clocks to match this program
Similar problem with claymore 11.2 to 11.4 but now Claymore has just released v11.5 with -oldkernel option which can be used in cases where they have problems with latest versions because they use hard OC and/or custom bioses created for old versions
any chance we can get a similar one for Phoenix so that there will not be need to change clock settings/bios mod
We haven't changed the kernels significantly in the last release but when we do in the future, we will most likely provide a way to use the older kernels if there are similar problems. Tried even a bit more than -20 on memory.
Getting this error:
wdog Hardware manager thread not responding
wdog Thread(s) not responding. Restarting.
In our experience, once you get the NVML 999 error, the only thing than helps is to restart the rig. So, if you get 999 error, first restart Windows, and then lower the OC. I have a weird thing, when mining PIRL I have 29mh/s but when I try to mine ETH Im getting 18mh/s. I tried ethermine and nanopool but nothing changed. Anyone got an idea ? I should get the same speed since its the same algorithm right ?
If you have an AMD GPU(s), most probably you have old drivers or haven't switched the driver in compute mode. PIRL has a low DAG epoch (less than 40), while ETH is at 175 already. The driver must be in compute mode in order to avoid losing hasrate with higher DAG epochs. would it be possible to get a fresh compiled version straight from the owen, or is it possible to get the source code so i can compile myself?
i need a fresh version because i allways get problems with precompiled binaries and AV.
PhoenixMiner is not open-source. To solve the AV problems, add the executable (PhoenixMiner.exe) as an exception in your AV. The false positives can't be avoided as most AV interpret the anti-debugging code in the program as suspicious. If you want to be extra safe, compare the hashes of the downloaded package with these that are listed in the first post of this thread - they must be identical. Can I mine other eth base coin, coz i tried to mine DBIX but it says that disconnecting to server... Am I missing something in my configuration?
My sample bat config..
PhoenixMiner.exe -pool stratum+tcp://beta-dbix.pool.sexy:10032 -wal 0xabc0419ec201fdccf5********* -epsw x -tt 65 -fanmin 55 -fanmax 90 -cclock 1130,1167,1130,1130,1130,1167,1167,1167,1167,1167,1167,1130 -mclock 2050,2100,2050,2050,2050,2100,2100,2100,2100,2100,2100,2050 -cvddc 850,820,850,850,850,820,820,820,820,820,820,850 -mvddc 850,820,850,850,850,820,820,820,820,820,820,850
We tried exactly the same command line but with valid wallet address and it works without any problems. Hi there,
Being using Claymore and had a steady hash rate at 243.5 Mh/s. Switched to PhoenixMiner 2.7c but hash rate fluctuates between 239+ to 248+ Mh/s; pool report an average of 242.4 M/hs. Does anyone hash rate fluctuates or it is just me?
We report the hashrate as (almost) unfiltered momentary value, which is exactly what the GPUs are giving at this time. You can also see the 5 minute average hashrate every 30 seconds or when you press the 's' key - this is much more stable and consistent value. As some people prefer more smoothed out values, we will probably add an option to set the amount of filtering. Hi Guys.
i am very happy with Phoenix Miner so far but i am having strange issue with Afterburner...i have Rx570 and 580 in my rig and in total 8 cards installed.Afterburner works perfect with old blockchain driver but when i installed latest adrenalin driver afterburner wont recognize my cards at all.all cards are good in windows device manager.Any advise?
Try to upgrade the Afterburner to the latest version (or use slightly older drivers but still from the 18.x.x generation, don't downgrade to 17.x.x as these have a lot of issues). Agree, I just use afterburner with nvidia cards, for amd I use OverdriveNTool, it works very nice!!
@PhoenixMiner
DevRequest: Forget about Dual mining on any other coin but XVG!!!!! PLEASE! Implement one of the multiple algoritms that Verge supports (Scrypt, X17, Lyra2rev2, myr-groestl, blake2s), you got options! Pretty please!!!
Will take this under consideration but the situation with these coins changes so fast that probably we will have to implement more than one and see which survives in the long run. Phoenix team can you make ASM kernel for rx 560 (baffin) ? Miner is considerably slower than claymore...
thanks
Hmm, PhoenixMiner does contain an optimized kernel for Baffin GPUs but perhaps it is not working well on your system. Could you please send us the first few pages of your log file and also tell us the driver version and overclocking settings of your card(s) to check what is causing these problems? Note that depending on your OC settings, the hashrate on RX560 could take a minute or so to pick up (you can play with -mi and -gt values to get more stable hashrate but make sure that the average speed isn't getting lower). |
|
|
|
Could you tell us what version of AMD drivers you are using and what behavior of the fans you are observing? We definitely can and will make improvements in the hardware control options but we need more information to troubleshoot any problems.
Blockchain 23 august 2017, it works like this -tt 60 -fanmin 85 -fanmax 85 -tmax 80, the problem about this is the fan will never be silent if the miner is not mining cause the min is 85%. On claymore you just need 2 commands to work -tt 60 -fanmax 85 cause as the fans will be at full speed since beginning to reach the 60c temp, once the fan reaches 60c then it lowers decrease the fan speed if less than 60c. So claymore is better in that sense. Thank you for the information. The blockchain drivers definitely doesn't work properly with our way of controlling fan speed and voltages (only the clock settings seem to work properly and reliably). The new drivers (18.x.x) have fixed almost all bugs in fan speed control (without any significant hashrate changes) so you can try them and see if they solve the problem for you. such a function is very necessary that would work without restarting the miner, this is like selecting the server in epools.txt while the miner is running, only with automatic switching and indicating how long and which wallet
Yes, this could be useful in some cases but we have a lot on our plate and it may take a while before this is implemented. @PhoenixMiner, I run PhoenixMiner 2.7c on 6 x GTX1070 Ti (Win 10 Pro build 1709) smoothly, until these last several days. Every time after I run it for several minutes, one of my cards suddenly lost its memory OC setting and back to is default memory setting. It happens when the miner restart, right after it crash (after connection error to "d3pool.eu/api/status"). I tried to ping " www.d3pool.eu", but the connection is okay and no packet loss. Here is what I found in the log file : ... Please help. Thank you. We need the log file of PhoenixMiner itself in order to make any conclusions. This log file doesn't contain any information that would tell us why the program is crashing or closing. Sorry for not reading all 50 Pages.
Is there a linux Version yet?
Thanks.
Not yet. Rest assured, whenever it's ready, it will be posted on the first page (and even on thread's title). PhoenixMiner 2.7c
1050TI
last nvidia driver
C:\Miner\PhoenixMiner>PhoenixMiner.exe -pool asia.ethash-hub.miningpoolhub.com:20535 -wal aneumoin.eth1 -pass x -proto 1 -mi 12 -log 0
Phoneix Miner 2.7c Windows/msvc - Release
-----------------------------------------
...
does not find shares.
Switching pools does not help
such a situation the last few days
why so little shares finds?
15.8 MH/s the speed is quite sufficient
This is just bad luck, nothing wrong with the log. @PhoenixMiner
is it possible to check what wrong with the the API used for monitoring apps, like "Claymore's miner monitor" by SIRIUS for android (currently at version 19.0214.P) ..?
It works fine with claymore, i get all gpu's temperatures, shares, uptime etc.. using PhoenixMiner, i only have access to miner log on port 3333, nothing else.
Same happens with other similar apps.
Thanks in advance.
We support the monitoring JSON API of Claymore but some programs may try to parse the log messages themselves, which obviously are quite different in PhoenixMiner. We are adding support for miner_getstat2 request too, which was missing in the current versions, so this should improve the compatibility. When is the next update and what can we expect, wish to use this miner?
In about a week there will be a beta release (maybe even sooner if no issues are found during the internal testing). There will be a lot of small improvements; support for -li, -tstop, and -tstart options; and some other changes... @PhoenixMiner
During the process of optimizing the OC settings I discovered the following bug:
After mining stable for a while the miner was stopped,
in the process of changing the memory clock setting from
-mclock 2150,2150,2150,2200,2125,2200,2150,2150
to
-mclock 2150,2150,2150,2200,2150,2200,2150,2150
and restarting the miner, the hash rate for GPU5 showed no change as a result of the clock increase. However, when the rig was rebooted, the hash rate now reflected the clock change.
It would appear that restarting the miner after setting changes (in this case the miner clock, may be true for other parameters as well) does not apply these changes (write to the hardware). Only rebooting Windows affected the change.
I am running:
Windows 10 1709
AMD 18.3.1
8 x RX580 8 GB
The problem is that there is no reliable way to get the default settings, without resetting all settings to the defaults. PhoenixMiner resets the settings to the default only if a "clean exit" is made with Ctrl+C in the command console. We can also reset the settings on startup but this may interfere with any other programs that are used for control of clocks/voltages/fans, etc. Perhaps the best way is to add an option -hwclean or something like this, which to tell PhoenixMiner that it is OK to reset the settings on startup. Phoneix Miner 2.6 Windows/msvc - Release
----------------------------------------
....
Eth: Connection closed by the pool
Eth: Giving up after 3 retries, switching to next pool
Eth: Reconnecting in 10 seconds...
any help from phoenix team?
2.6 and 2.7c
everything is working until it stops getting shares from the pool. tia
This seems like a connectivity problem - the connection is established and then closed by the pool. This is typically result of too much memory overclock. Lower the memory overclock on this card by 20-30 MHz and the problem should go away. |
|
|
|
@phoenixminer Can anyone help me with this? 2.7c Ive been running this since it came out and Ive noticed slowly my mining rate is going down and down over the weeks. yet in someways the speed has either gone up or at least stayed the same - the amount mined in a week is going down. i have a pair of 1080ti's as an example: https://imgur.com/4NUafKn.jpg The graph here is from ethermine.org and is for the last 24 hours. These are within the normal variations for a 24-hour period. However the amount mined per week (or whatever time period you want) doesn't depend only on hasrate but also on the difficulty, which is climbing as more and more mining rigs are added to the network. Claymore 11.3 recently introduced a custom RX550 asm kernel now I see this: We also ordered an RX550 so there will be optimized kernels for it in the next release.
coincidence ? You should ask Claymore about this. We are responding to a perfectly reasonable complaint that our miner doesn't support RX550 with optimized kernels, which you can see here: https://bitcointalk.org/index.php?topic=2647654.msg31697743#msg31697743I have been testing this miner and so far it looks pretty stable in all fronts except fan settings which claymore still has the upper hand, for example -tt 60 -fanmax 90 on claymore works flawless, on this example, the miner will keep 90% fan speed until it hits 60c but it does not work like this on this miner. I wonder why.
Could you tell us what version of AMD drivers you are using and what behavior of the fans you are observing? We definitely can and will make improvements in the hardware control options but we need more information to troubleshoot any problems. +1 for linux version.
Please PM me if you have beta version so I can work on implementation within nvOC and do some preliminary tests before implementing it in the next version of nvOC.
Thanks!
We will definitely do that. However we aren't there yet. We'll try to squeeze this in the next full release.
Hi developers PhoenixMiner! Is it possible to implement the function of switching between the primary and backup pool in time? for example every 2 hours to switch for 30 minutes to another pool with another purse?
It would be very easy to implement it using batch or powershell. Run first command line, set a timer to kill the process, run the second command line, set a second timer, repeat. You don't even need to kill the process, you can use the -timeout <n> option in combination with -rmode 0 to force the miner to shutdown after n minutes. What about dual mining? A you going to add second coin?
Yes, but no specifics on when and what algorithms will be supported. |
|
|
|
Thank you, it appears that the console freezing problem only manifests on Windows 10 ver 1709 or later, and we were testing on earlier Windows builds (we have disabled Windows Update on our test rigs). Now we are able to reproduce it reliably and we will find a fix. We also ordered an RX550 so there will be optimized kernels for it in the next release. Defender wont let me have to file on desktop, Defender automatically delete it.
Is it possible the programmer adapt this program and be safe ? Why does it detect a virus ?
In such case, you have to temporarily disable the Windows Defender real-time protection; then move the files in the desired folder, extract them, and add the folder as exception in Windows Defender. Yes, ideally we would like for these false positives to disappear as well, but it is not up to us. We only had positive response from Kasperski, and even they just flagged the particular executable as safe. We have to resubmit the executable for reevaluation on each release, and hope that they will do it again. Most other AV vendors don't even respond to our requests. In order to avoid this automatic false positive detection, we must disable most of our anti-debug measures, and we are reluctant to do this. Hello,
The 010, 011 options for pausing cards above nine would be great! I understand that using letters really limits what you can do with other commands so this would work just as well.
For others who are saying just use -gpu, that would work too but what I am trying to do is PAUSE all GPUs during a single start of Phoenix miner and then "unpause" each GPU individually for troubleshooting. It's just a faster way to check things out GPU by GPU while the others are paused versus restarting the miner turning on each GPU I want to check.
And I am also looking forward to a Linux version as well to give my 3GB cards more mining options due to DAG size and Windows 10 use of GPU memory.
Thanks again!!!
Then it will appear in this way in the next release. We are working on the Linux version but in the meantime you can use Windows 7 to avoid the Window 10 stupid problems with 3GB cards. We are running our 1060 3GB under Windows 7, mining ETH and ETC without any problems. hi
why nanopool don't see my hash using phoenix ?
soon i stop claymore i "lost" all my hash on dashboard of nanopool
how to fix it ?
Send us (or paste here) your .bat file (or at least the PhoenixMiner.exe command-line parameters). Most probably you have an error in the wallet address (or you haven't changed it from the default example address). When is the Linux version coming?
ASAP (hopefully in about a month).
Try this to reproduce:
Try scrolling back and holding that position for a bit. ( like your try to read whats on the screen there. )
Then scroll back some more without letting it return to the current line, and hold there for a bit.
When ever I do that, and then let it release is when the issue happens for me.
Thanks, we managed to reproduce it, it appears only on Windows 10 ver 1709 or above. Hi! Happy to use this miner it's work perfectly and I'm using it with 5 rigs of 12 GPU each (RX580,GTX1070/TI/1080TI ...) since month now, and I'm an early adopter of PhoenixMiner. Everything is fine until last upgrade (2.7c) where I meet 2 strong problems appearing on 2 of my RIGS (and not the others): - first a crash of the miner show CUDART errors (never met before) - then the software is trying to launch a new session BUT keeping the previous one alive, showing the GPU with 0.000 MH/S and many errors. Then server is KO. First errors appearing: https://preview.ibb.co/iu5jTS/minersproblem.jpg--> random "CUDART error in CudaProgram.cu:434 : an illegal memory access was encountered (77)" crashing my miner. Then after the 1st error above when miner is trying to launch itself through a new session BUT the previous one stay present under W10 so GPU are having 0.000 MH/S ... https://preview.ibb.co/mjpToS/phoenixminercrash.jpgI'm on W10PRO, latest drivers, etc... everything uptodate. Of course I tried to lower OC and so on, without success. What's in common with those 2 RIGS: having RX580 NITRO+ with HYNIX memory (1st rig with 12 of those cards, the others with 6 of them + 6 GTX). Any idea how to solve please? Thanks Phoenixminer devs and other members!:: The CUDA errors are consistent with memory overclock problems in Nvidia GPUs but as you have tried to lower overclock the reason is probably something else. The problems on the AMD cards are related to inability to allocate DAG (are the cards 4GB?) Try to add the option -eres 0 to avoid overallocation of the DAG buffer. We are making some changes in the CUDA code in 2.8, that should increase the stability and speed a little. |
|
|
|
Thank you for the great tool.
Is it possible to specify SINGLE GPU above 9 ie 12?
-gpus 12 doesn't work
I have 15 cards and I want to do burn test of the particular 12 GPU.
Best regards,
CiN
You can also use a little "trick" like this: -gpus 12, (notice the comma after 12). This will allow you to specify a single GPU above 9. |
|
|
|
Yes. Using 2.7c
The Freeze with the "E" on the screen happens to me any time I try to scroll back.
Have to exit miner and restart it.
We will look into this, the problem is that it doesn't happen on our test rigs but we will find a way to reproduce and fix it. ...
I've been running the miner now for a few weeks and it's superb, except for the mentions below:
1) the miner doesn't seem to be optimized for the RX550's as attempts your miner with them the resulting hashrate is ~7+, while Claymore gets ~10+. Is it optimized for them and I'm doing something wrong, or can the you make it compatible if it's not?
...
Well, we don't actually have any RX550 cards here so it is probably running the generic kernels, which are slower. We will try get some and make better kernels for them for the next release. Hi All,
Just want to say thanks to the developers for this mining SW. It is working GREAT on my 12 card rig that uses a Biostar TB250 BTC-Pro motherboard.
I have one simple request.
How can I pause mining on cards 10, 11, and 12 or higher?
if you could add a feature where a=10, b=11, c=12, ... or something like that it would be great for rig trouble shooting that is related to hardware.
Thanks!
We can do it for example like this: type 010 for card 10, 011 for card 11, etc. The variant with letters will work too (and it is easier with just one key press), but it takes too much of the available letters for other commands. Thanks for the request, will try to include it in 2.8. Hello,
Every 24 hours or so I get this;
17596:15:34:21.877: GPU2 CUDA error in CudaProgram.cu:437 : the launch timed out and was terminated (702)
17596:15:34:21.933: GPU1 CUDART error in CudaProgram.cu:434 : the launch timed out and was terminated (6)
17596:15:34:21.972: GPU2 GPU2 search error: the launch timed out and was terminated
17596:15:34:21.972: GPU1 GPU1 search error: the launch timed out and was terminated
I'm assuming it's power draw or OC related (both are not aggressive so I'm assuming it must be the power limit), however from this can you deduce that GPU 2 is the culprit or is it too hard to tell?
Thanks!
Try to lower the memory overclock on GPU2 (or increase the core voltage if you are undervolting it). Dev, solo is here you da man! BUT I do have a couple of comments:
1. Your example at the top of your 2.7c release says -coin Vic and Akroma, but down in the list you don't list either of those. Can you please amend or tell us a full and accurate list of coins that work under the -coin feature please.
2. I am using drivers on my AMD cards that run like a bat out of hell speed wise on low DAG coins but once I go back to high DAG coins it goes to sheet. But I only mine low DAG coins so it does not matter to me. But an issue I ran into is that I have all along used -minspeed in clay to reset my miner and re-apply my OCs when they fail and whatnot, but because the dev DAG is high by default, the -minRigSpeed calculates the devfree speeds into its feature, thus, unless I mine a -coin I cannot use -minRigSpeed because the DAG lowers my MHS during the devfree periods and calls up my -r function. Even though my own mining is at a nice and high tweaked speed. Clay does not calculate the DevFree periods into the -minspeed totals.
3. I am switching to solo Vic now so will try the -coin Vic to avoid the DAG switching high and impacting the -minRigSpeed mis-calulations for a work around for now. (more of a statement). My last coin was not available under the -coin feature thus I could not use the -minRigSpeed feature and had numerous OC drops were I went periods un-optimized by a card or two.
4. Am I wrong or is the capitalization for the command lines are required. If it is spelled out as -minRigSpeed in the instructions then you have to use -minRigSpeed as -minrigspeed wont be recognized. Seems kind of trivial and I am sure causing more folks then just myself a headache. unless I am wrong and this was just a 4AM sleep issue.
1. Done, thanks for noticing. 2. We don't mind excluding the DAG generation from the average speed to avoid this problem. Will try to fix this in 2.8. 4. Yes, the command-line options are case-sensitive. We will fix this too in 2.8, you are absolutely right that there is no need for them to be. Stable. but fans are loosing settings for AMD after some time and goes higher up to 95% fan speed then back, then up. I opened afterburner and use its fan setting - all is good when I use AB. -tt 55 -fanmin 55 -fanmax 85 Could you tell us the driver version? There is nothing wrong with sticking with AB, if you are happy with it. Hi devs, LOT of people are still waiting for linux version  Sad... We know, we are working on it Hi, I cannot do anything because Windows defender detect a virus and delete everything. https://ibb.co/iBhNDSIs it possible to fix it in 2.8 please ? The best way to fix the problem is to add the folder(s) where you keep (and download) the miner software to the Windows Defender exceptions as specified here: https://support.microsoft.com/en-us/help/4028485/windows-10-add-an-exclusion-to-windows-defender-antivirus. As a last resort, you can turn off the Windows Defender real-time protection then turn it back on after unzipping the archive and adding the folder as an exception (besides its brain-dead attempts to delete PhoenixMiner, Windows Defender can be useful in detecting real threats). Has anyone been able to get an improvement in hashrate when adjusting the -gt parameter? In most cases, my hashrate goes down significantly when going very high, or stays the same when adjusting slightly.
Does it affect shares found or reduce stales, or is it just meant to give a slight boost in overall hashrate and performance? What exactly is the -gt parameter for?
No, the only benefit from non-standard GT value(s) is the potentially increased hashrate as it is printed on the console every few seconds. Yes, the default GT value is the best for most cases but not always - if you can't increase the hashrate by changing GT, leave it as it is by default and forget about it. |
|
|
|
If I get an incorrect share on Pheonix Miner, because of OC, how can I tell what GPU got an incorrect share? is there a way like Claymores?
Yes, both the correct and incorrect shares are shown for each GPU every few seconds like this: Eth speed: 145.071 MH/s, shares: 2980/0/1, time: 23:34
GPUs: 1: 27.665 MH/s (579) 2: 27.901 MH/s (581/1) 3: 29.795 MH/s (564) 4: 29.646 MH/s (574) 5: 30.063 MH/s (682) On the first line you can see the total number of correct shares for the whole rig (2980), rejected shares (0), and incorrect shares (1). On the second line are the per-GPU stats, and the number of correct shares for the first GPU is 579 (no incorrect shares), for the second GPU it is 581 correct and 1 incorrect share, and so on. Rejected shares are not shown per-GPU as they are not meaningful in this context. I don't use both miners at same time but can't connect anyway
Could you tell us which version of Claymore's remote manager you are using? We have tested even with the latest one (3.8 ) and all seem to work without problems. seems 2.7c isn't as stable as 2.6 on my 1070's .. miner crashes after several hours.
This is strange, there are no changes in CUDA kernels between these two versions. The only change that could affect stability is the smoother transition between normal ming and devfee that was introduced in 2.7a, and it should have the opposite effect. Do you see a connection between the crashes and devfee switches? I keep getting this error , at random times, sometime after 48h sometimes after 20 minutes.
It does not matter if I OC or NO.
I get it with stock and overclock settings , i have changed the risers , checked cables etc. Reinstalled windows set pagefile bigger, added ddr. New nvidia drives old driver does not matter. Tried -eres 0 1 2 does not help.
I also need to mention that i have 2 rigs with 100% same specs , 1 with days of uptime no issue. 1 constantly needs to be rebototed.
My Rig
6x 1070 / 008 risers / 2x HX850i Psu / Biostar BT250 Mobo.
PM 2.7c
PhoenixMiner.exe -pool eu1.ethermine.org:4444 -wal XXXXX.MRORIG02 -proto 3 -cdm 0 -nvidia -eres 0 -minRigSpeed 170 -rmode 2
...
Thank you for the log and for the detailed description of your setup. It is telling that all the GPUs seem to fail simultaneously so this isn't a problem with particular GPU. We will try to reproduce the problem here and implement some kind of workaround in the next release. Hello guys . Yesterday i installed the new version 2.7c , and i let the miner for 5 hours ... He found only 92 shares , compared to claymore , claymore found 181 shares in 5 hours . Should i go back to 2.6 ?
You should also compare the share difficulty. For example ethermine.org has 4000 MH difficulty and nanopool has 10000 MH difficulty. So even if the hashrate is the same, you should expect to find 2.5 times more shares on 4000 MH share difficulty than on 10000 MH. Tried 2.7c for 10mins. Within 1 min, 1 of my RX580 dropped from 30.5mh/s to 24mh/s and remain at that speed. Temp same as using ver 2.6. Infact I used same bat. file as ver 2.6.
Revert back to 2.6 immediately and hashrate goes up to 30.5mh/s for that gpu. My rig consist of mix of gtx 1070s and rx 580s in one rig.
Will continue using 2.6 until 2.7c becomes better.
Could you post the commnad-line parameters (or the config.txt if you are using it instead)? @PhoenixMiner Thank you for your continuing development of this great miner  I found 2.7c very good although I had 1 problem today we had a power cut lost internet connection. Now that 2.7c is SSL enabled which we were using. We found that looking at console when the system loses internet connectivity the miner tries to resolve addresses, but it seems to look for port 4444 as though somewhere specified as default pool in the miner exe itself. It then hangs because it could not connect to that being SSL enabled. I didn't get chance to test again just stopped miner and restarted making sure we had connectivity and the miner carried on as normal. What I have done now is set a fail over second pool being same eu address with 5555 in the hope that if it fails again in might try this before trying to resolve the 4444 port. Just a heads up if you need to look into this at all in the event that this might happen leaving the miner hanging. The miner now reports on start up 4 pools specified. So somewhere there are 2 otherwise specified in the code I persume. The pools that are specified in the command-line or config.txt (via the -pool and -pool2 options) are the first and second pool. The pools specified in the epools.txt are then added to the list. If there are no pools in the commnad-line, all pools come from the epools.txt. We don't have any hard-coded pools or ports in the PhoenixMiner, except the devfee pools/ports. Probably you have seen the devfee trying to connect (you can recognize it is the devfee by the DevFee: prefix in the console and in the log file, the normal mode uses the Eth: prefix). anyone here knows how to force 2GB mode?
What do you mean by "2GB mode"? PhoenixMiner
Ethereum mining only. What are the best values for the –gt for pascal cards with DDR5 and DDR5+, separately? The value for the most occupied MCU (memory controller). For DDR5+ memory especially. Or this parameter does nothing for nvidia pascal cards?
The GT parameter is only for AMD cards. Because Nvidia cards generally can't be BIOS-modded then wouldn't benefit so much from such fine-tuning. Hi I am trying to change from Claymore to Phoenix miner (8x Rx580 and 2x GTX1060) from some time ago... with 2.6 version... now trying with 2.7 version. But something weird happens. With phoenixminer I get a lot of flotation on hashrates... se pic: https://imgur.com/a/vOsEQwith claymore hasrate is very linear and stable...  We show the momentary hashrate as it is (with very little filtering). However as there seems to be a lot of questions like this, perhaps we should use more filtering to smooth out the peaks and dips and show "nice" smooth hashrate average for at least 15-30 seconds. For those who want to see the momentary hashrate, there will be a commnad-line parameter to choose the time window for hashrate smoothing. I'm getting FATAL ERROR: Debugger detected
With Phoneix Miner 2.7c on 6x1070 rig with windows 10 latest build and nvidia driver 391.01
Im using this string
-rmode 0 -cdmport 23334 -cdm 1 -pool europe.ethash-hub.miningpoolhub.com:17020 -wal Etherion -pass x -proto 4 -coin auto -nvidia - gpus 123456
Im assuming it's the driver. Which would be recommended?
Unfortunately, as you are already using the -nvidia option, we just don't know why the anti-debug code is kicking in. reconnect problem.
while phoenix work best and have lower stale shares
only the problem is the connection problem.
first if miner cant connect the pool at the first time, it will not connect forever unless you close the miner and double click a new miner again
second sometime if lose connection to the pool while mining like say after a few hour, it will also not connect forever unless you close the miner and double click a new miner again
you can duplicate this problem by reboot modem or router
please resolve this
....
From the log it seems that there is really no connection and the miner is trying all pools one by one. However there were some substantial changes in the networking code of 2.7c because of the new Solo/GetWork mining support, so we will double check this. Seems like the phoenix 2.7c update was released just after Claymore's version 11.2 claims minor improvement in hash rate and less stale shares due to optimizations.
I wonder if Claymore's changes have also been incorporated here.
No, the changes in 2.7c (since 2.7b) are entirely in the network stack: SSL support for stratum pools, and Solo/GetWork mining support. |
|
|
|
author=PhoenixMiner
I have a problem with the connection to ethereum.miningpoolhub.com
at the address specified by us-east.ethash-hub.miningpoolhub.com:20535 the miner does not connect.
you have an entirely different address in the example us-east1.ethereum.miningpoolhub.com:20536. Where does this address come from?
at this address connects but the number of rejects exceeds 50%
how to make the miner work concretely with asia.ethash-hub.miningpoolhub.com:20535?
my sample
PhoenixMiner.exe -pool asia.ethereum.miningpoolhub.com:20535 -wal aneumoin.eth1 -pass x
-proto 1
-mi 12
-log 0
Also, make sure that all command-line options are on the same line - in your post appears that everything after -pass x is on the next line(s). |
|
|
|
SSL works. cool.
@PM suggestion: show the SSL in the console.
Yes, we realized that there is only one message that indicates a secure connection. We will fix this in the next release. hi
i'm getting "CUDART error in CudaProgram.cu:172 : unspecified launch failure" every 10 or 15 minutes.
what could be possible reasons and how to solve it?
This is part of the DAG-generation kernel. What coin you are mining? Try to specify the coin you are mining with the -coin xxx command-line argument (xxx could be one of: eth, etc, exp, music, ubq, pirl, ella, etp, pgc, akroma, whale, or vic; see the Readme.txt or the first post for details) to avoid unnecessary DAG generation during devfee periods. Does SSL give more stale shares?
No, it doesn't affect the stale shares or effective hashrate in any way. It just encrypts and authenticates the connection between the miner and the pool, making the man-in-the-middle attacks impossible. i'm getting error FATAL ERROR: debugger detected
Gigabyte rx570
-amd option key doesn't help
Sorry about that. We will make some changes in this code in the next release of PhoenixMiner to lower the probability of this thing happening. So far we have determined that tool old or non-official drivers may be one of the reasons for the problem. The best thing to compare is the number of found shares for given time period. Obviously this requires a significantly longer test period but even in your example you can see 43 shares from PhoenixMiner for 26 minutes and 42 shares from Claymore for 28 minutes. Also, you can compare the 5 min average hashrate on PhoenixMiner, which is 278.578 MH/s in your case, and 1 min average hashrate on Claymore, which is 278.149 MH/s in the second screenshot. Also, if you want to increase the hashrate of PhoenixMiner "to the max", specify the -mi 12 command-line option but keep an eye on the stale shares. Finally, you should lower the overclock on your GPU3 (the third GPU) because it is giving more incorrect shares than correct ones - anything over 0.1-0.5% incorrect shares on given GPU is just not worth it. had a weird problem today. windows performed some updates and detected the phoenix miner exe as a trojan (i know it's false) and deleted the file, which killed the miner. turned off windows active protection, re-extracted 2.7b, then restarted it. after a couple hours it stopped again. upon restarting it it would give me an error about not having the proper priviledges. run as admin (wasnt needed before), and then it says it cant find the phoenix miner exe despite still being there in the same directory as my .bat file.
downloaded 2.7c and the problem seems to have gone away.
The best way to fix the problem is to add the folder(s) where you keep the miner software to the Windows Defender exceptions as specified here: https://support.microsoft.com/en-us/help/4028485/windows-10-add-an-exclusion-to-windows-defender-antivirus. Otherwise, it can delete the executable again in the most inconvenient time, even while the miner is running. Whats the best tunning for RX580 8G ? I've got lower rates than at 11.2
Claymore monitoring at port 3333 doesnt work. Sayed failed.
As we stated above, printed momentary hashrate is not the best way to compare miners. Compare the number of shares over exactly the same time period (at least 1-2 days). As for the remote monitoring, the port 3333 must be free. If you are running PhoenixMiner and Claymore at the same time, use the -cdmport option of PhoenixMiner to change the port to something else (e.g. 3334) and use the same port when trying to connect to PhoenixMiner from the remote manager. author=PhoenixMiner
I have a problem with the connection to ethereum.miningpoolhub.com
at the address specified by us-east.ethash-hub.miningpoolhub.com:20535 the miner does not connect.
you have an entirely different address in the example us-east1.ethereum.miningpoolhub.com:20536. Where does this address come from?
at this address connects but the number of rejects exceeds 50%
how to make the miner work concretely with asia.ethash-hub.miningpoolhub.com:20535?
Hmm, sorry about that, this is obviously a typo on our part. We will fix it. As for the connection problems, make sure to specify the -proto 1 command line option when connecting to the ethash pools of miningpoolhub: PhoenixMiner.exe -pool asia.ethash-hub.miningpoolhub.com:20535 -wal YourLoginName.WorkerName -pass x -proto 1 |
|
|
|
Phoenix, is your 2.7B optimized for the latest AMD drivers ? It seems slower than the 2.6 with my 2 RX570 and blockchain drivers.
No, we haven't made any changes that could cause this in the 2.7 branch. So I figured I'd give Phoenix a try. I installed 2.7b and ran for about 18hrs.. Obviously, this isn't a good complete comparison, but wanted to take a look.
Here are my thoughts after this short test.
Displayed hash rates were slightly higher, but this was too short to be meaningful
I really liked the additional info in the console screen. # of shares found for each card, 5min average hash, etc.
Very easy to setup and start. No problems at all...
Here's where I had an issue. I'm currently running a single rig with 5 RX580s. (One is in the "shop" for repairs). Everything seemed to be stable last night when I set it up.. When I woke up this morning, I noticed one of my cards was running at 28Mh/s instead of it's normal 31+. I looked and it had reset it's settings.. I use OverdriveNTool and it's been extremely reliable for OC and undervolting. So I thought maybe it was a fluke, so shut down miner and restarted and everything was running fine.. Went out this morning and when I got back, that one card had reset again.. I'm not sure if it's resetting during the dev fee mining or what, but it has reset twice in 18 hours.. Same card.. So I have switched back to Clay for now.. If there is some debug logging I can turn on, I'm happy to help diagnose the issue.
The card resetting is a Sapphire Nitro+. I also have 2 XFX and 2 Gigabyte cards and they kept running fine... I'm using the default batch file settings that came with the download other than adding the call to my "overclock.bat" file that loads my OverdriveNTool settings at mining startup.
I'm open to any suggestions... I love the lower dev fee and additional info, but stability has to be the top priority for me..
Keep up the good work and let me know if I can help figure this out...
Thanks,
Russel
Thank you for trying our miner. Could you please let us know the driver version that you were using on the rig and the OverdriveNTool settings? Not stable for me. I get fluctuating hash rates. Not sure what the issue is.
I've never seen the hash rate stay stable on PhoenixMiner. I've been trying it for about a month at least and the hash rates moves up and down always. I don't know if that's common for everyone, but always for me. An example for me is a GPU fluxes between 29.5 to 30.2 back and forth. All my GPU's do that to some degree. Maybe the Dev's at Phoenix can address that phenomenon to let us know if it's an issue or why it does that. Doesn't seem to effect mining or shares but is interesting on why. We don't think that this is an issue - we just show the momentary hashrate as it is, without overuse of digital filtering to smooth out the fluctuations. If you want to know the average hashrate over longer period of time, the 5 minutes average speed that is shown every half minute or so (or when the 's' key is pressed in the console) is the best choice. Greater miner running stable for the past several hours.
Not sure if this was said here already. One improvement, in my oppinion, that would be great is an option to set the network difficulty. For instance if you solo mine, and you have a sare that exceeds te difficulty it would be nice to see how many times you submited shares over a certain difficulty range.
Thank you for the idea, it will probably find its way in PhoenixMiner 2.8. Forget about dual mining, is not profitable at all, now most are asic, who cares.
Better make devfee optimization and other features and support for other coins that use GPU and are asic resistant.
As we said, we will be a little less open about our future plans to avoid leaking information that could help the competition. But rest assured, we have a few surprises fro the future releases Question to PhoenixMiner
Please give an honest answer for this question as I haven't see a post lately from you.
With all the crap about the GPU kernels going on between you and Claymore I would like to
know if your miner is going to stay in business. You and Claymore are the few that actually
know for sure if you lifted code from their miner. I don't know. I hope not.
I like the PhoenixMiner and it is faster than Claymore and currently seems stable.
But, I don't want to waste my time trying and testing it if it's going away.
If you plan to keep developing, releasing new builds, improvements and new features I will keep
using it, otherwise I need to go back to Claymore and carry on. After all, I'm mining to
make some money and wasting time is not on my schedule.
Let us all know what your plans are for the future.
Thanks
We are absolutely committed to the development and improvement of PhoenixMiner for a long, long time! In fact, we are quite encouraged by the overwhelming support and positive feedback here and elsewhere. Our share of the ethash miner market is still very small but it is rising fast and even started accelerating after the recent events. |
|
|
|
PhoenixMiner 2.7c is officially released. In addition to the changes in 2.7a, and 2.7b, we have added support for secure stratum connections using SSL (supported by ethermine.org) to prevent the increasing IP hijacking attacks. To connect to a secured pool, use the ssl:// prefix (e.g. -pool ssl://eu1.ethermine.org:5555). We have also Added support for solo mining (HTTP GetWork protocol). We are switching our attention to 2.8, which will include a lot of small improvements, as well as some big ones but we prefer to keep them confidential for now in order to avoid giving any ideas to the competition We also continue working towards dual mining and Linux support as our next major milestones.
|
|
|
|
@PhoenixMiner:
you use my GPU kernels in your "fastest" miner, 100% match of binaries. I can prove it if you are not going to confirm it.
So do you confirm it?
No, we certainly DO NOT confirm it. We believe that you've tried (and apparently you think you succeeded) in extracting our kernels using reverse engineering techniques. That wasn't very nice of you to say the least but we have expected something like this, just not that fast. In some sense it is flattering but also a little annoying. The first version of our kernels was obtained from someone on this very forum for quite a bit of coins. They were a little bit slower than the best miner on the market at this time - yours - but we decided to use them to jump start our project anyway. After a lot of tinkering with Polaris GPUs we found out how to increase the speed a bit and improved the kernels a lot, achieving higher speed and/or lower consumption than your miner (in most cases). The original versions were left as a honeypot for particularly persistent reverses which apparently did its job quite well Now, are these old kernels the same as old versions of yours? We don't know for sure but we doubt it, and we can't just take your word for it (especially after throwing accusations like this after basically admitting that YOU are trying to reverse OUR miner), and because they were slower than your miner, and they do not support dual mining at all (and dual mining is still the killer feature). But even if they were, frankly this isn't our problem - we've paid handsomly for them, and we haven't used them in any of the publicly released versions, so we won't lose any sleep over this. If you beleive so, search for a digruntlet employee, or perhaps your unnamed source(s) at AMD? I decided to check your miner as soon as I noticed that you have same tuning option ("+" and "-" keys in runtime) that works exactly as my -dcri option, also your miner has no "optimized" kernels for same set of chips as my miner. After checking I found 100% match in GPU kernel on GPU. Now you are talking about some "old unknown" kernels and you don't use them anymore and have super-protection that can fool me and so on... okay. I will create step-by-step guide how to confirm that you send my kernels to GPU and you will say that your miner uses "old unknown" kernels because it detects dumping but still mines at the same speed. That's funny answer, but you don't have better one, I understand. So my word against yours. The result is obvious for me, however, since I call you a liar, anyone who wants to confirm by yourself that this miner uses my kernels can PM me and I will send step-by-step guide how to do it, then you can say the results; no newbies please, be at least sr.member on this forum, just to be sure that you don't want to become another "phoenixminer" and spend my time again... Do what you've got to do of course - obviously you feel strongly about this and believe that this is well worth your time It's just not exactly clear what you are trying to prove though - we already conceded that our old/honeypot kernels might be the same as your old kernels but this is not very likely. But since you are willing to provide the blobs of your kernels in these PM sessions, our kernel guy would certainly like to take a look, so thank you. Frankly we've got a lot of respect for you, and if you have chosen to contact us via PM with your concerns, we would have respected that and checked if there is any merit in your claims but you've come swinging and accusing us in our thread and if you expect us to just sit there and take it, you are quite wrong. It is also quite wrong of you to assume these things: - That you can't be fooled by our anti-reversing measures (really do you think that we can't detect dll-injection attacks?).
- And that, if you do succeed in extracting our real/current kernels and leak them in the open, we can't do the same with yours. "We know" a guy that was part of the driver development team of AMD and he is itching to test its kernel-level emulator by trying to extract your current kernels. Heck, if he's successful, we can even put your kernels in our miner and let the users select them explicitly and see for themselves how they compare with ours.
Anyway, we prefer to concentrate our efforts on improving our miner bit by bit (we are still lacking in many areas) but if you want to play this game, we can play it too. Just keep in mind that we were nobody in comparison with you just a few weeks ago, and you seem resolute to put us on the map so to speak, for which we thank you - it well known that controversial or bad publicity is always better than no publicity at all. |
|
|
|
|
Show Posts
