Are you working on the 3080?
Not yet, but we received both 3080 and 3090, waiting for 3070. After the ETCHash work is finished, we will switch focus to the new GPUs.
In WINDOWS10 system, using "-li" "-gpow" will cause the CPU usage to become very high, can it be solved?
We can't reproduce this problem. Please tell us what GPU you are using, and the full command line (plus config.txt, if you are using it). Please note the following:
- -li should not be used together with -gpow - pick one or the other
- If you are using -gpow, make sure that -mi is not 0 or any other small value - it must be at least 6-7
- If you are using your main PC with your main GPU for mining, just add -mi 0 and do not use -li or -gpow - this will allow relatively smooth work on the display while the card is mining. Of course, the hashrate will be lower but you can't have both high hashrate, and quick to react GPU
hey i can't use the straps for RX580 o just for AMD VEGAS CARD ? comon guys <3
We will be adding straps support for Polaris in a future version. For now, if you haven't modded the BIOS, use
-mt 2, which works on most cards and increases the speed in comparison with the stock VBIOS.
Amazing guys! Been waiting for this feature. Any idea if it will be available on Linux too? I would love to use HiveOS with memory straps without having to mod bios.
Yes, there will be Linux support for -straps too.
"Normal" ETC and ETH mining runs properly, but with very fluctuating (56-60Mhs) hashrate!
Also with 5.2e still invalid shares (only) on Nicehash!
6800/6800XT are not supported with native kernels - we don't have either card yet, so the miner falls back to the generic kernels, which are slower and produce more stale shares. Additionally, NiceHash just rejects all stale shares, and that is exactly what you are seeing. You should add
-stales 0 when mining on NiceHash to avoid sending known (to miner) stale shares that will be rejected anyway. In order to minimize the stale shares when mining with the generic kernels, you may try to lower the mining intensity -mi to 10, 9, or even lower value. This will lower the speed somewhat but with 10-12% stale shares, it should be worthwhile trade off.
Any hopes for the 1070Ti ?
Any smart fixes ?
What is the problem with 1070Ti? It is probably the only Pascal GPU that still does 30-31 MH/s without problems with bigger DAGs, while the 1070 are affected by the DAG size and won't mine with the former speed with these big DAG epochs.
Unfortunately this won't be the case as soon as DAG 384 will be reached.
As soon as you reach this dag the performance drops by 50%
In our test rigs all is fine even at epoch 400 - 1070Ti mining with over 30MH/s. If you are running Windows, try using older drivers (in our test rigs with 1070Ti we have drivers 397.64, and 456.71 - both work fine). If you are running Linux, you may try to add use 8 GB RAM on your rig, if you are running only 4 GB RAM now.
Both 5.2e and 5.1c sometimes detect one extra card
.....
There are 6 cards in this rig so GPU 1 and GPU 2 is the same card. Needless to say this does not end well
So far I have managed to run 5.1c over some time but not 5.2e
Windows 10
Most probably mixed-up drivers. Remove the drivers with DDU, then check if they are really removed - they should be listed only as "Microsoft Basic Display Adapter" not as Radeon .... If necessary, run DDU again until you see only "Microsoft Basic Display Adapter"s in the Device Manager, only then install the new drivers.
Since yesterday I get:
Disabling DAG per-allocation (not enough VRAM)
ON 8GB 570/580
This is intentional - do not worry about it, the miner will force -eres to 0 for the next few epochs. The reason is as follows: there are two methods to create and organize the DAG buffer on AMD cards: the first one is better as it provides slightly higher hashrate, and slightly lower power usage. However it stops working when the DAG size is over 3.9-4 GB, and we are forced to use the second method. The exact limit depends on the drivers but eventually (around epoch 379-384) even 6GB and 8GB cards will have to use the second method. We are disabling the DAG pre-allocation (i.e. forcing -eres 0) in order to be able to use the first method as long as possible. Once the limit is crossed, the second method will be used and -eres will work again as expected.
When I put -rxboost 1 on bat file, I've this error
https://prnt.sc/vogc65I don't know why
AMD 20.11.2 drivers
5.2e PH
4gb rx 570 (1) and (3) rx 580 4 gb
regards
The errors are pretty clear - you have to run your .bat file with the "Run As Administrator" and make sure that EIO.dll, EIO.exe, and IOMap64.sys from the PhoenixMiner package are in the same folder. It is not enough to just copy the PhoenixMiner.exe from the new package if you want to use the "-rxboost" option.
After Epoch 377 i got only 9.3 MHz no matter what i try/
Driver 20.11.2
Miner 5.2e
Any help?
Try using -daglim with lower values (the default is 4023). See the other recommendations for 4 GB cards in the first post of this thread.
Hi!
I have some trouble with my rig (6 x RX588 and 1 x RX564)
When start phoenix miner him don't want start mine on all cards. start only rx588 cards.
Why he exclude my GPU0 RX564 ?
2020.11.23:19:09:29.779: main Phoenix Miner 5.1c Linux/gcc - Release build
2020.11.23:19:09:29.779: main Cmd line:
2020.11.23:19:09:29.779: main config.txt: -mport 3335 -rmode 2 -logfile /var/log/miner/phoenixminer/phoenixminer.log
2020.11.23:19:09:29.806: main Unable to enum CUDA GPUs: no CUDA-capable device is detected
2020.11.23:19:10:01.540: main Unknown OpenCL driver version! Hashrate and stale shares may suffer
2020.11.23:19:10:01.540: main OpenCL platform: OpenCL 2.1 AMD-APP (3143.9)
2020.11.23:19:10:01.540: main Unable to use OpenCL device Radeon RX 560 Series (pcie 1) for Ethash mining
2020.11.23:19:10:01.540: main Available GPUs for mining:
2020.11.23:19:10:01.541: main GPU1: Radeon RX 580 Series (pcie 2), OpenCL 1.2, 8 GB VRAM, 36 CUs
2020.11.23:19:10:01.541: main GPU2: Radeon RX 580 Series (pcie 3), OpenCL 1.2, 8 GB VRAM, 36 CUs
2020.11.23:19:10:01.541: main GPU3: Radeon RX 580 Series (pcie 4), OpenCL 1.2, 8 GB VRAM, 36 CUs
2020.11.23:19:10:01.541: main GPU4: Radeon RX 580 Series (pcie 6), OpenCL 1.2, 8 GB VRAM, 36 CUs
2020.11.23:19:10:01.541: main GPU5: Radeon RX 580 Series (pcie 7), OpenCL 1.2, 8 GB VRAM, 36 CUs
2020.11.23:19:10:01.541: main GPU6: Radeon RX 580 Series (pcie 8), OpenCL 1.2, 8 GB VRAM, 36 CUs
You need to run PhoenixMiner 5.2e, not the older version 5.1c.
hi
After a mining failure on version 5.1c, when an out of sync occurred, all my rx580 cards slightly decreased the hash rate, but the main thing was that the power consumption changed. All my fine tuning of the cards crumbled, I have to look again for the minimum working voltage, increasing it in comparison with the previous settings. please optimize power consumption in the next versions
Try using newer drivers (20.5.x or later) and PhoenixMiner 5.2. However eventually (after several weeks at most) even the 8GB cards will have to switch to second method for DAG generation and organization as explained above. We are looking for a ways to remove this additional inefficiency caused by the big DAG buffer, but it seems that it will be hard to avoid. The good news is that it is not getting worse once the limit is crossed - the hashrate at epoch 400 and 450 is almost the same, the same goes for the power consumption.
Dear Phoenix.
DAG splitting can fix Nvidia 1070-1080 series problem? Have you tried this?
Thanks.
Unfortunately, no. We tried a lot of things, including some very clever tricks to increase the locality of memory accesses and lower the pressure on the TLB cache but the result was even worse than before.
Thanks for the hard work.
5.2e shares still invalid 4.5% (only) on Nicehash!
2020.11.23:15:09:40.431: main GPU0: GeForce RTX 2060 (pcie 1), CUDA cap. 7.5, 6 GB VRAM, 30 CUs
2020.11.23:15:09:40.431: main GPU1: GeForce RTX 2060 (pcie 2), CUDA cap. 7.5, 6 GB VRAM, 30 CUs
2020.11.23:15:09:40.431: main GPU2: GeForce GTX 1060 6GB (pcie 4), CUDA cap. 6.1, 6 GB VRAM, 10 CUs
2020.11.23:15:09:40.431: main GPU3: GeForce GTX 1660 Ti (pcie 6), CUDA cap. 7.5, 6 GB VRAM, 24 CUs
2020.11.23:20:35:59.183: main *** 5:26 *** 11/23 20:35 **************************************
2020.11.23:20:35:59.183: main Eth: Mining ETH on daggerhashimoto.eu.nicehash.com:3353 for 5:26
2020.11.23:20:35:59.183: main Eth: Accepted shares 1069 (0 stales), rejected shares 39 (1 stales)
2020.11.23:20:35:59.183: main Eth: Incorrect shares 0 (0.00%), est. stales percentage 0.09%
2020.11.23:20:35:59.183: main Eth: Maximum difficulty of found share: 4105.5 GH (!)
2020.11.23:20:35:59.183: main Eth: Average speed (5 min): 111.862 MH/s
2020.11.23:20:35:59.183: main Eth: Effective speed: 113.61 MH/s; at pool: 109.73 MH/s
2020.11.23:20:36:02.460: eths Eth: New job #d6707f67 from daggerhashimoto.eu.nicehash.com:3353; diff: 1932MH
2020.11.23:20:36:02.842: main GPU0: 43C 53% 113W, GPU1: 65C 78% 126W, GPU2: 47C 57% 83W, GPU3: 39C 49% 78W
As explained above, nicehash rejects all stale shares. We can discover only some of the stale shares, but not all because only the pool itself decides which share is stale. In your case even
-stales 0 won't make a big difference because only one of the rejected shares was discovered to be stale by the miner itself.
Thanks for version,
Phoenix i got one question,
I have one rig of vega 64, drives is 19.5.2 and last phoenix miner,
I tested the -tt target option and i get some questions:
1 - I observe that if i put the parameter -fanmin <35 , the software always force it to 35.
2 - the fans will always spin at ~35% or will adjust adaptively to mantain the target temp and even could stop when we got really cold weather? Im seing that overdriventoool P0-P4 stages became all populated with 35º, with this how gpu maintain an target temp if is always 35% ?
3- On new drives we can´t use an target temp? only %?
I´m confused
Thanks
Try using -fcm 2 or newer drivers. -tt with target temperature should work without problems. If it still doesn't work with the latest drivers, send us a log file to diagnose the problem.
Hello, i am sure this question was asked a lot of times - but i never needed it
i was just running PM miner since it exists with not much overtuned cards and it always worked without issues!
now i wantes to run it as an admin ,- in windows i am logged in as an admin, -but to run the bat file as an admin - after starting it says this is not an internal command?
what do i make wrong?
THX
You only need to run it as administrator if you are using -rxboost or -straps. Check if the .bat file works normally (when not run as administrator) first. To diagnose possible problems, you can also open the "Command Prompt" as Administrator (you should see Administrator:Command Prompt in the title bar) and then run the .bat file from there to be able to see any errors.
Hey... me again
...
....
I don't know what's wrong with hashrate GPU 4... I'm using PH 5.2e and 20.4.x drivers (1 rx 570 4 gb and 3 rx 580 4 gb). That one is rx 580 (gpu 4). Compute mode enabled, OC, changed riser, Windows 10... etc...
After starting the .bat, no more than 5 minutes pass and it indicates some problem with the threads. My head will blow up
Regards
Try using -daglim with lower values for the last GPU (the default for Windows is 4023). In your case use
-daglim 1,1,1,4016 to set the DAG limit for the last card to 4016MB and the first three will be on auto (4023MB).
does the straps command work for rx cards ? right now i have to ruin claymore and phoinex in tandem and i hate it.
claymore for straps and phoiniex cuz its more stable
Not yet, will be implemented in a future version. For now, you may try
-mt 2 -rxboost 1 which should give you a good speed up if the cards are not modded.
when etchash is released and dag size is the below 3gb again....can I then use turbo kernel on 5700 8gb and boost hashrate?
interresting question for the new amd 6000 series as they all have 16gb ram. must take any hashrate advantage of that huge memory
From our testing only the Polaris memory controller benefits from the dual DAG buffer of the turbo kernels, there is no speed up on Vega, or Navi. We haven't tested RX6800 yet but it is unlikely that it will provide more speed with dual DAGs as it seems quite similar to Navi in this respect. On Polaris cards with 8GB however, the turbo kernels will work as expected for a long time when using etchash.
