Crazy stuff, my single RX580 get recognized as two RX580 GPUs. and mining at 12MH/s each,
while fan stays at 0 rpm, until it crashes due to overheating
Does anyone have latest AMD driver and latest 2004 windows 10 version, and its working well?
Probably a driver issue with two OpenCL drivers each reporting the same GPU. We had somewhat similar issue with DDU not removing the drivers completely - to be sure, please check if all Radeon GPUs are missing from the Device Manager after DDU finishes and restarts the PC (and before installing the new drivers) - you should see only the iGPU and generic "Microsoft Display Adapter" GPUs there. If there is a Radeon GPU still recognized, DDU must be started again to finish the job before installing the new drivers. On a related note, you will need PhoenixMiner 5.1b for the latest AMD drivers 20.7.1 to work properly. I'm getting a strange occurrence. It took me a while to troubleshoot and I just can't seem to figure out what's wrong. After a random amount of time (anywhere between 5 minutes to almost 2 hours), the miner will "pause" and indicates to press any key to continue at which point it just shuts off. There's no error message. It just says "pause Press any key to continue..." Does anyone know what might cause this? Thanks!
Check if something emulates pressing 'p' in the console window (it may be some process that "feeds" text data to the standard input of PhoenixMiner and if 'p' occurs there, the miner will be paused). |
|
|
|
The new beta version is ready. You can download PhoenixMiner 5.1b from here: (MEGA links are no longer active) If you want to check the integrity of the downloaded file, please use the following hashes (you need the last file PhoenixMiner_NVRTC_Windows.zip only if you want to mine BCI with Nvdia cards under Windows): File: PhoenixMiner_5.1b_Windows.zip
===================================
SHA-1: b71a5b22bb9a6fbd26d4a85272f73defabad2b70
SHA-256: 1592d04efa4ef427b6e42388d012ac6a68154f09848aaaa4f0418e3425e07155
SHA-512: c543b8bc5d0c345e81fb2586b2807b842fc2b666bd033ceb78820d1732a61ef8529a228f9df8777029dfc9f7a8e90853fa65600c4d3b976787e1630f0ea03dfd
File: PhoenixMiner_5.1b_Linux.tar.gz
====================================
SHA-1: 9ba244a12698ca30015ef273c9f3cd9a9443c04f
SHA-256: ade4a07bd0c738fb875b2a42b5153271fedd23c60ba4527655360a8f718be4de
SHA-512: 860491408731c63bf42bb8288711de2f29534b4bac14313e376869d221a62a985ce4ea1a5a22cb39d875eb876016aa741275702665cc3ee1116c5cc3637ec21c
File: PhoenixMiner_NVRTC_Windows.zip
====================================
SHA-1: ff6fa5e018adbd52caf631c42b7c2fac7ce48a51
SHA-256: 8087757169405d51ea8ba818347fb05d0450aef985c29272165070346eb5a54a
SHA-512: 7b2d832f7f40578bb1f501d5174467f5ae06612e601dab769fd56d39da48a471b18c6373435a485155f70fec4017d8378797bf1e1dfe5d62fee30fa6a1d992c4
The new features in this release are: - Added support for VRAM timing adjustments for Nvidia cards of 10x0 series (see the new command-line parameters -straps, -vmt1, -vmt2, -vmt3, and -vmr for more information)
- Added -ttli option to automatically decrease the mining speed to avoid overheating the GPUs over the target temperature (useful when -tmax option is not supported by the drivers)
- Added support for latest AMD drivers 20.7.1 under Windows and 20.20-1089974 under Linux
- Fixed long-standing problems with -gpow option, which now works properly
- Many other small improvements and fixes
Here are some additional notes about the VRAM timing adjustments of Nvidia 10x0 cards: - Most recent Nvidia drivers require running as administrator (or as root under Linux) to allow hardware control, so you need to run PhoenixMiner as administrator for the VRAM timing options to work.
- The four independently adjustable VRAM timings are controlled by four different parameters: -vmt1, -vmt2, -vmt3, and -vmr. The last one controls the memory refresh rate, and the first three are other timings. The possible values for each of them are from 0 to 100, where 0 are the default timings, and 100 is the most aggressive timing (most GPUs probably wont work with 100).
- The -straps option gives an easy way to set one of the predefined levels of VRAM timing adjustment. The possible values are 0 to 6. 0 is the default value and uses the default timings from the VBIOS. Each strap level corresponds to a predefined set of memory timings ("-vmt1", "-vmt2", "-vmt3", "-vmr"). Strap level 3 is the fastest predefined level and may not work on most cards, 1 is the slowest (but still faster than the default timings). Strap levels 4 to 6 are the same as 1 to 3 but with less aggressive refresh rates (i.e. lower "-vmr" values).
- When using the VRAM timing options, start with lower values and make sure that the cards are stable before trying higher and more aggressive settings. You can use -straps along with the other options. For example -straps 1 -vmt1 60 will use the timings from 1st strap level but -vmt1 will be set to 60 instead of whatever value is specified by the 1st strap level. In such case the -straps option must be specified first.
- The VRAM timing options can be quite different between the GPUs, even when the GPUs are the same model. Therefore, you can (and probably should) specify the VRAM timing options separately for each GPU.
Please let us know if you have any problems or questions related to PhoenixMiner 5.1b. |
|
|
|
Could you help me with this? I watch a lot of videos in information about the 5700XT, with Hashrate of 56/57 MHS ...
I have managed to reach that speed by modifying the timings of the BIOS, but the RIG crashes, I can only keep it stable around 54.5Mhs, if I upload OC from memory to get more speed, it hangs in a few minutes or in several hours.
Is there a way to make the 5700XT stable with 56MHS and the Rig not crash?
This is highly dependent on the concrete card. Possible tips: keep the memory temperature low (by using lower -tt), try tools like More Power Tool, and so on. solve trouble with pool switch crashing. old bat file option -retrydelay 1 bad. change to -retrydelay 10 all ok
Good to hear! It's generally not recommended to use -retrydelay value under the default 5, especially on rigs with many cards. Hi there,
I've been running 5e for a couple of days, but just today, Windows Defender is saying it's detected a Trojan:
Trojan:Win32/Bomitag.D!ml
E:\PhoenixMiner_5.0e_Windows\PhoenixMiner.exe
Any comments?
This has been answered many times before - due to the way we prevent reverse engineering of our code, many AV tools freak out. In the beginning we tried to reason with them but the problem kept repeating after each new release, so now we just gave up. As long as you have verified the checksums published here against the downloaded archive, you don't have anything to worry about.
Please tell us the driver version and the Windows version, and the version of PhoenixMiner that you are running. Also, the log from the start would help much more than just the last several lines.
I use Radeon Software Crimson ReLive Edition Beta for Blockchain Compute Driver for Windows® 10 64-bit, Windows 10 Pro x64, and Version PhoenixMiner 5.0e AMD cards with 4 GB won't work with the blockchain BETA driver after epoch 350-353. You need to upgrade your drivers, to at least 18.x.x - see the first post of this thread for details. Hi, about my question, tested on drivers from 18.6.1 to 18.9.3 on them the reduction in the core frequency works, on drivers above this version it does NOT work, on the latest version 20.5.1 it does not work either. Now in the summer the -tmax parameter is very relevant, please look and if possible implement it on drivers above 18.9.3
I use most of the video cards PowerColor Red Dragon/Devil RX580, but there are others 580 series (Sapphire, Gigabyte) they also do not perceive this parameter, program Phoenix 5.0e, Windows 10 LTSB/LTSC
I'm using -tmax but it's not working
I read the whole README and couldn't find any similar automatic control.
All cards are Asus RX 580 4GB
Windows 10
PhoenixMiner_5.0e
Driver Version 20.4.2
We will look into adding -ttli (or similar) functionality in the next release. Hi
Is it possible to display blocks found in Solo Mine?
We need to display the block found
In any card
In Solo Mine
Thanks
If you are solo mining directly on a full node (not pool), then each found share is an actual block (or uncle). If you are mining on a pool, the pool determines the difficulty and we don't know if it is enough for a block solution or not. This is because the network difficulty changes all the time and is not transmitted by any pool. Even if we use the information that is gathered by -astats from third-party websites, it is out-of-date most of the time. We may add some additional information in the next release but only when -astats is specified. do we still need to flash mining vbios on this or does pheonix suppots vbios straps like claymore?.
We are working on general memory timing straps but they aren't ready yet. For now, you can use either VBIOS mod or thrid-party tools like AMD Mem Tweak. Another solution is the -mt 2 option but it isn't as powerful as the VBIOS mods or AMD Mem Tweak. Hi phoenix!!! AMD added new drivers a linux 20.20 and Windows !!!
Yes. In another driver "masterstroke" the new Windows driver is also version 20.5.1 like the last one, despite that it was released in June and should be 20.6.1 instead. Let us repeat: do not upgrade to drivers that are newer than the version of PhoenixMiner you are using. So, do not upgrade to the new 20.5.1 (the one from June 10) or the 20.20 Linux drivers yet. |
|
|
|
So many rejected shares on 5.0x verisions... About 1-1.2% overall rejected shares (not stales or incorrect) on my RX 580 8Gb rigs...
Could you please tell us on which pools? This is normal on nicehash, as it doesn't accept stale shares and they count as rejected shares, and it seems that recently nicehash started changing the jobs more often, leading to more rejected shares. Yes, it's on nicehash. Is there some way to correct show these stale shares? We only can detect a part of stale shares - these that are discovered after we have received a new job. However, due to the delay in the pool itself and the network latency, most stale shares can not be discovered at miner level. So we send these shares and nicehash rejects them. We could take into account when the job last changed and if a share is rejected soon after a job has changed we can count it as stale instead of rejected but this won't be 100% reliable. However the bigger problem is that nicehash really doesn't count the stale shares at all unlike other pool that give reduced reward for stale shares, so it won't be correct to count them as stale in the statistics - you won't get any reward from them anyway. There is nothing you can do unless you connect the display to 8 GB or 6 GB card. As this isn't possible in your case, you can instead run separate instance of PhoenixMiner for just GPU1 (adding the argument -gpus 1) and use a pool that only mines ETH. The other five cards will run on another instance of PhoenixMiner (with -gpus 23456), that can mine both ETH and ETC. How to make this? With a 2 bat files? I will have 2 miners on the screen or is it possible to make in one? Yes, make two different bat files and run them both. You will have two console windows, it's not possible to combine them as they are independent from each other. One thing to be aware of, if you are using remote control port, is to change the port number in one of the bat files to something else than the default port with this command-line argument: -cdmport 3334 (this will change the remote control port to 3334, the default is 3333). hello,
I have 2 rigs where the GPU 1 still don't mine ETH :/
and the one which works, have the same problem when I bench epoch 360
W10, latest AMD drivers, 4Go GPU, -eres 0.
Problem is, on the opposite of claymore, phoenix reboot the miner automatically instead of having GPU 1 at 0 hashrate and letting the rest mine.
normallyall my rigs have the same configuration, I don't know why it works better on somme than on other.
Does someone have an idea?
thx
An obvious question but are you running PhoenixMiner 5.0e? If so, please send us a log to check for any problems in it. why did my miner stop when I started to DAG # 352? and doesn't reboot by itself, 2020.06.11:05:45:24.320: GPU5 GPU5: Starting up... (0)
2020.06.11:05:45:24.320: GPU5 GPU5: Generating ethash light cache for epoch #352
2020.06.11:05:45:24.342: GPU3 GPU3: Starting up... (0)
2020.06.11:05:45:24.398: GPU6 GPU6: Starting up... (0)
2020.06.11:05:45:24.444: GPU2 GPU2: Starting up... (0)
2020.06.11:05:45:24.559: GPU4 GPU4: Starting up... (0)
2020.06.11:05:45:24.604: GPU1 GPU1: Starting up... (0)
2020.06.11:05:45:27.189: main Eth speed: 0.000 MH/s, shares: 5/0/0, time: 0:02
2020.06.11:05:45:27.189: main GPUs: 1: 0.000 MH/s (1) 2: 0.000 MH/s (0) 3: 0.000 MH/s (1) 4: 0.000 MH/s (1) 5: 0.000 MH/s (1) 6: 0.000 MH/s (1)
2020.06.11:05:45:28.011: GPU5 Light cache generated in 3.7 s (16.3 MB/s)
2020.06.11:05:45:28.248: GPU3 GPU3: Allocating DAG (3.77) GB; good for epoch up to #354
2020.06.11:05:45:28.280: GPU3 GPU3: Generating DAG for epoch #352
2020.06.11:05:45:28.520: GPU6 GPU6: Allocating DAG (3.77) GB; good for epoch up to #354
2020.06.11:05:45:28.575: GPU6 GPU6: Generating DAG for epoch #352
2020.06.11:05:45:28.814: GPU2 GPU2: Allocating DAG (3.77) GB; good for epoch up to #354
2020.06.11:05:45:28.849: GPU2 GPU2: Generating DAG for epoch #352
2020.06.11:05:45:29.109: GPU4 GPU4: Allocating DAG (3.77) GB; good for epoch up to #354 thank you for your help Please tell us the driver version and the Windows version, and the version of PhoenixMiner that you are running. Also, the log from the start would help much more than just the last several lines. |
|
|
|
PhoenixMiner 5.0e is officially released. You can find the download link and the checksums in the first post of this thread. The changes in this release are: - Additional fixes for the problem with crashing or slowing down when switching from ETC to ETH mining
If you are already running PhoenixMiner 5.0b, 5.0c, or 5.0d, it is recommended to upgrade to 5.0e, especially if you are using pool that switches coins automatically like nicehash.
|
|
|
|
Not a message like this. Everything looks ok in the beginning, but when it starts to change from epoch to epoch first gpu starts to mine with a lower speed and after a while the miner crash.
P.S. My monitor is on GPU 1...
There is nothing you can do unless you connect the display to 8 GB or 6 GB card. As this isn't possible in your case, you can instead run separate instance of PhoenixMiner for just GPU1 (adding the argument -gpus 1) and use a pool that only mines ETH. The other five cards will run on another instance of PhoenixMiner (with -gpus 23456), that can mine both ETH and ETC. Is this what you're after Phoenix? Thanks for the prompt reply too!  I can Private message you a complete "log file" if you think it will help, but other than down the bottom where is says "Agent Service Error", I don't see anything abnormal. And as I say, everything is identical to the other 4 rigs, in every way. Please ignore the Maxhash pool below.. it was a test to see if it was an Ethermine issue.. but same result. Cheers. bin: phoenixminer
conf: phoenixminer.pcfg
[707] 2020-06-08 09:37:10Z: (CLI user) Using port 4028...
[707] 2020-06-08 09:37:10Z: (CLI user) Starting screen 'miner-4028' with: /opt/miners/phoenixminer/phoenixminer -epool stratum+ssl://eth-eu.maxhash.org:13011 -ewal 0x972e782f1a165ac661ef716a5f1fcb283a85563a.Rig4 -epsw x -mport 4028 -allpools 1 -logfile /var/log/phoenixminer.log -logsmaxsize 100MB -eworker Rig4 -fanmin 35 -tt 66 -tstop 75 -clGreen 1 -acm -amd -mclock 1960 -cclock 1040 -mvddc 800 -cvddc 800 -mode 1
[707] 2020-06-08 09:37:12Z: (CLI user) Miner screen started...
[707] 2020-06-08 09:38:38Z: (CLI user) Starting command line miner on localhost
bin: phoenixminer
conf: phoenixminer.pcfg
[707] 2020-06-08 09:38:38Z: (CLI user) Using port 4028...
[707] 2020-06-08 09:38:38Z: (CLI user) Starting screen 'miner-4028' with: /opt/miners/phoenixminer/phoenixminer -epool stratum+tcp://eth-eu.maxhash.org:8011 -ewal 0x972e782f1a165ac661ef716a5f1fcb283a85563a.Rig4 -epsw x -mport 4028 -allpools 1 -logfile /var/log/phoenixminer.log -logsmaxsize 100MB -eworker Rig4 -fanmin 35 -tt 66 -tstop 75 -clGreen 1 -acm -amd -mclock 1960 -cclock 1040 -mvddc 800 -cvddc 800 -mode 1
[707] 2020-06-08 09:38:40Z: (CLI user) Miner screen started...
[707] 2020-06-08 09:56:40Z: (CLI user) Miner stopped.
[722] 2020-06-08 09:58:19Z: (FCTRL) service started.
[722] 2020-06-08 09:58:19Z: (FCTRL) Agent Server Error:
[722] 2020-06-08 09:58:32Z: (FCTRL) local IP is 192.168.1.72.
[722] 2020-06-08 09:59:05Z: (CLI user) Starting command line miner on localhost No, we need the log from the miner itself, which in your case appears to be in /var/log/phoenixminer.logHi All. please tell me can I mine Ravencoin now or at the future with PhoenixMiner?
Thanks.
Now it isn't possible as Ravencoin uses another variant of ProgPOW. We may add support in the future but there is no specific timeframe. Jutst to report that Phoenix 5.0 works fantastic on Ubuntu 18.04.4 with Amd 20.10 drivers. Much much batter than Claymore in Linux.
Nice to hear So many rejected shares on 5.0x verisions... About 1-1.2% overall rejected shares (not stales or incorrect) on my RX 580 8Gb rigs...
Could you please tell us on which pools? This is normal on nicehash, as it doesn't accept stale shares and they count as rejected shares, and it seems that recently nicehash started changing the jobs more often, leading to more rejected shares. |
|
|
|
Hi Phoenix! You added nvidia Cuda 11 lib?
Not yet, but we are preparing some Nvidia goodies in the next release, so stay tuned. I am with a driver version: 19.4.3 and Phoenix Miner 5.0e Windows/msvc - Release build. When the miner makes a DAG for epoch #340 is ok. But the 4GB card stops when the miner starts to make a DAG for epoch #351.
We have tested with the same driver version and it works without issues. Please send us the log to assist you further. Probably the 4 GB card is used by Windows and doesn't have enough free VRAM. You have to either use an integrated GPU or put an 8 GB card as the primary adapter. Guys, could you help me. I got stuck when trying to start Phoenix miner. My last lines from the log are: 2020.06.08:20:37:33.819: GPU1 GPU1: Starting up... (0)
2020.06.08:20:37:33.819: GPU1 GPU1: Generating ethash light cache for epoch #351
2020.06.08:20:37:33.823: GPU2 GPU2: Starting up... (0)
2020.06.08:20:37:33.825: GPU3 GPU3: Starting up... (0)
2020.06.08:20:37:33.826: GPU4 GPU4: Starting up... (0)
2020.06.08:20:37:33.828: GPU5 GPU5: Starting up... (0)
2020.06.08:20:37:33.830: GPU6 GPU6: Starting up... (0)
2020.06.08:20:37:33.833: GPU7 GPU7: Starting up... (0)
2020.06.08:20:37:33.875: main Listening for CDM remote manager at port 3333 in read-only mode
2020.06.08:20:37:37.771: GPU1 Light cache generated in 4.0 s (15.2 MB/s)
2020.06.08:20:37:38.685: main Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:00
2020.06.08:20:37:38.685: 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) 7: 0.000 MH/s (0)
And here Windows is saying that the program stopped working and it's closing it. I tried 5.0b and 5.0e - same. The cards are RX470 4GB Sapphire Nitro. Maybe it's the driver? It's old, but working with Claymore: 22.19.659.1 Thanks in advance... The blockchain driver does not support the larger DAG buffer that is required for epoch 350 or later. Please upgrade to newer driver and remember to put all cards in Compute mode in the AMD Control Center. Hi all. Can someone please try and point me in the right direction. I have been running Phoenix Miner forever. I have 5 x identical mining rigs, each with MSI B360fpro MB, 8gb Ram, i3-8100 cpu and 10 x MSI RX 570 4gb gpu's, all mining ETH through Ethermine. All have been running sweet, then 1 rig stopped mining. I have checked all I can, stripped the rig back to a single gpu (and tried a few just in case).. the miner starts, but just will not hash. The miner screen shows it's trying, just looks like it's not attempting to build DAG? I've tried V5.0b, c and d. All same. I reformatted/reimaged (running PiMP, which has been/is awesome), copied and pasted the settings from one of the other stable rigs.. still same problem. I loaded "cough" claymore for testing purposes.. and it fired up right away, and has been hashing stable for the past 12hrs. It's got me puzzled, as I said, I have 4 other identical rigs running no issues? If Claymore runs, surely Phoenix should too?? The only thing left for me to do is assume its hardware and swap parts from a working rig.. 1 x 1.. painful.  Any thoughts would be appreciated. Thanks in advance. Please send us the log from the problem rig, we can't offer any sensible advice without the log. This shouldn't be happening especially when mining ETH, which is only at DAG epoch 340.
Let us know if this fixes the problems.
pool swith trouble again. manual pool swith crash too miner cash then switch back to main pool. lot of different rig crash on pool switch We tried to reproduce the problem with the same driver version and the same pools but it works fine. Please check the page file size, it should be big enough for all the DAGs (roughly 4 GB for each GPU plus a few additional GB for Windows use). |
|
|
|
We added additional fixes and some workarounds for the ETH to ETC switching problem in the new version PhoenixMiner 5.0e, but with some Linux drivers, there is no full stability (e.g. 19.20 are crashing if the miner starts mining ETC then switches to ETH but not if it goes ETH, then ETC, then ETH, and so on). But even with 19.20, switching should work fine until about 5-7 DAG epochs before the RAM of 4 GB cards would not be enough for mining ETC. You can download PhoenixMiner 5.0e from here: (MEGA links are no longer active) If you want to check the integrity of the downloaded file, please use the following hashes (you need the last file PhoenixMiner_NVRTC_Windows.zip only if you want to mine BCI with Nvdia cards under Windows): File: PhoenixMiner_5.0e_Windows.zip
===================================
SHA-1: 19eb7292d34593576e069ccfec96ede30ed135a0
SHA-256: 97c1e17afc501c41643e4c5d54bc8b705041931fa69ce89bf6ebcbd6de2a4c0f
SHA-512: f6671f1afa373bd01769e4e20d0d171f6b8df8c9d49f2858d81ea51f49969ab76c9390de28cffdbb62efdcaad22309b0a7eac637b5db7b6151074590d1511c23
File: PhoenixMiner_5.0e_Linux.tar.gz
====================================
SHA-1: edf362bffc3291a4038c4deef80cad2131743b30
SHA-256: 3d98b14bd9753cbd0a0e2c5cc2de8136f6963c52db74df252fe33e5ad6b21df7
SHA-512: 3c1ffe93a323b0e9cbdd06a540f790b0f83030efe5c7cf87107b49a77808c1177ac2b19e493af083fc5abf546b618f78a99b7960e6befdebc14a712c4e0c8f1c
File: PhoenixMiner_NVRTC_Windows.zip
====================================
SHA-1: ff6fa5e018adbd52caf631c42b7c2fac7ce48a51
SHA-256: 8087757169405d51ea8ba818347fb05d0450aef985c29272165070346eb5a54a
SHA-512: 7b2d832f7f40578bb1f501d5174467f5ae06612e601dab769fd56d39da48a471b18c6373435a485155f70fec4017d8378797bf1e1dfe5d62fee30fa6a1d992c4
Let us know if this fixes the problems. |
|
|
|
|
We found an additional problem when switching from ETH to ETC but it seems it depends on the OS and driver version (and affects mostly Linux and only 4 GB AMD cards). We'll be ready with a fix or workaround tomorrow.
|
|
|
|
We have just released PhoenixMiner 5.0d that should fix the problem that some are experiencing when switching from ETC to ETH mining. You can find the download link and the checksums in the first post of this thread. The new features in this release are: - Fixed problem with crashing or slowing down when switching from ETC to ETH mining
|
|
|
|
PhoenixMiner 5.0c is officially released. You can find the download link and the checksums in the first post of this thread. This is a minor update over 5.9b with support for the latest AMD Windows driver. The new features in this release are: - Added support for latest AMD Windows driver 20.5.1
- Added SO_REUSEPORT option on the remote control port (default 3333) under Linux to prevent problems when the miner is restarting
If you are already running PhoenixMiner 5.0b, there is no need to update to 5.0c unless you want to run AMD Windows drivers 20.5.1, or need the small improvement for the Linux version.
|
|
|
|
OpenCL 19.20 AMD Driver
OS: HiveOS 0.6-142@200528
linux Ядpo 5.0.21-hiveos
4Gb AMD Asus Cards STRIX
Phoenix 5.0b
after epoch 350 in Nicehash Ethash I have low hashrates ~ 10-15 mhs from card. after creation ETC DAG
-dagrestart 1, dont solve the problem. ((
What I am doing wrong? Thx a lot
We have tested with the same Linux drivers 19.20-812932 on Ubuntu 18.04 LTS (slightly older kernel but still 5.x) and everything works fine. Please check your other settings (i.e. clocks), and make sure that you are using auto-tune to find the best -gt values (they could be very different than before DAG epoch 350). Also, sometimes just restart of the rig solves such strange problems. NO I DIDNT SEE THAT
AND IAM USUING THE BLOCK CHAIN DRIVER FROM 2017 "22.19.659.0"
The blockchain driver is not tested with the new big DAG kernels and probably is not working properly. Install newer drivers (anything from 18.12.1.1 to 19.7.5) and make sure that you have switched the GPU Workload to Compute mode (by default they are in Graphics) in the AMD Control Center. Dear Phoenix,
Do you have any plans to add the DAG-split feature to your miner?
For AMD - to allow 8-gig cards to continue mining ETH after the DAG exceeds 4GB
For NVIDIA - to fix the ETH speed reduction because of the raising DAG (on 10xx cards)
We will definitely continue to support AMD 8 GB cards in the future. However this approach probably won't solve the Nvidia slow degradation of hashrate with each new DAG epoch. I did some testing and it appears that there is a problem with -clkernel 3 on 8GB cards, the turbo kernel does not work anymore, changing back to -clkernel 1 did the job but it gives a little less hashpower. PhoenixMiner or someone, could you please verify and confirm the same problem. PhoenixMiner tnx and keep up the good work.  There are no changes in -clkernel 3 - it is working as it was before. The problem is in the AMD drivers, which start to partially allocate shared memory (i.e. the mainboard RAM) as part of the DAG buffer as the used VRAM approaches 7.4-7.5 GB, which leads to sharp decrease in the hashrate. So, unless they fix it in the future drivers, -clkernel 3 is not viable for epoch 350 and above. I tried both versions of the miner 5b-5c and at least 5 types of drivers and the maximum speed I achieved is 10.4m per card. The cards are RX 580 4G. I will be happy if someone shares if this problem can be fixed.
Please check if your cards are switched to Compute mode in AMD control center. It is easy to miss if you are coming from the blockchain drivers, where there wasn't such option. Hi all, Fairly new here to mining (as of 2 hours ago), Can anyone help me with this please ? Eth: Giving up after 3 retries, switching to next pool Eth: Reconnecting in 5 seconds... Eth: Connecting to ethash pool us2.ethermine.org:14444 (proto: EthProxy) Eth: Connected to ethash pool us2.ethermine.org:14444 (172.65.226.101) Eth: New job #c02829d6 from us2.ethermine.org:14444; diff: 4000MH GPU1: Starting up... (0) GPU1: Generating ethash light cache for epoch #339 Eth: New job #89396b4b from us2.ethermine.org:14444; diff: 4000MH Eth speed: 0.000 MH/s, shares: 0/0/0, time: 0:01 Light cache generated in 3.8 s (15.6 MB/s) GPU1: Allocating DAG (3.66) GB; good for epoch up to #341 CUDA error in CudaProgram.cu:373 : out of memory (2)GPU1: CUDA memory: 4.00 GB total, 3.33 GB free GPU1 initMiner error: out of memoryFatal error detected. Restarting.Error 2 while trying to restartI have a Nvidia GeForce GTX960 4gb ddr4 on a AMD FX8320 rig with 32gb ddr3 running win10 The problem is that your video card is probably used by Windows and there are only 3.33 GB free VRAM, while the Ethereum DAG buffer requires 3.66 GB VRAM as you can see the the log file. So, you have either mine another coin with lower DAG epoch, or mine on another video card, with more free VRAM. |
|
|
|
There is a new version, which is a minor update with support for the latest AMD Windows driver. You can download PhoenixMiner 5.0c from here: (MEGA links are no longer active) If you want to check the integrity of the downloaded file, please use the following hashes (you need the last file PhoenixMiner_NVRTC_Windows.zip only if you want to mine BCI with Nvdia cards under Windows): File: PhoenixMiner_5.0c_Windows.zip
===================================
SHA-1: ef3158ffb1071abbbde0091fc18e03eec5823d8e
SHA-256: b95bd34653877f1b664ba897369ee5663298dbdd837377528201966371b03c6f
SHA-512: be775ef9dd552f82b07f74ebceaa6804f3f7f16f32fed21a6971a24b8e6534d6ec82cedf17d3433936e6f69ef0887014a5cfb6fd9869adaeeaf9ed7505c6e14c
File: PhoenixMiner_5.0c_Linux.tar.gz
====================================
SHA-1: e41b6eb9da7e5bdb68eb153dbe846ac7ab765395
SHA-256: 1f21303b2d7f0e939c3867067a9daeacec9157efec7c4362d0a433481f489b5d
SHA-512: 994069ccec68fda53e1c04e6ac4133b0d5f31719ec359d271dc3ce03b156217ba0522126a35bf8d46b3317a2be1cdb256e30a569056df37718c0639645c3a8cc
File: PhoenixMiner_NVRTC_Windows.zip
====================================
SHA-1: ff6fa5e018adbd52caf631c42b7c2fac7ce48a51
SHA-256: 8087757169405d51ea8ba818347fb05d0450aef985c29272165070346eb5a54a
SHA-512: 7b2d832f7f40578bb1f501d5174467f5ae06612e601dab769fd56d39da48a471b18c6373435a485155f70fec4017d8378797bf1e1dfe5d62fee30fa6a1d992c4
The new features in this release are: - Added support for latest AMD Windows driver 20.5.1
- Added SO_REUSEPORT option on the remote control port (default 3333) under Linux to prevent problems when the miner is restarting
There is no need to update to 5.0c unless you want to run AMD Windows drivers 20.5.1, or need the small improvement for the Linux version. Please let us know if you have any problems or questions related to PhoenixMiner 5.0c. |
|
|
|
Thanks and I'm sorry. I wanted to as about drivers for GTX1070 on Win 7. I have 8GB physical RAM (2 * 4GB DIMM). But basing on your answer I think it does not matter in acase of Win 7 if I use 1070 or 1080. I have problem that my mining speed decreased and decreased each time. Only power limit increasing fixes it, but it costs additional electricity. If I will use win 10 I will not have these problems? Or may be it will be better to use HIVE OS (If in any case I should install other OS instead of Win 7)?
No, unfortunately the same problem is present in Windows 10 and Linux. Unless Nvidia solves it at driver level (e.g. increase the size of memory pages like AMD did with Polaris), which is highly unlikely, there is no fix for this problem. Thanks for the clarification! Installed the latest driver and it worked!
Note that you can use the latest supported by PhoenixMiner Windows driver, which is 20.4.2 for PhoenixMiner 5.0b. The new driver 20.5.1 won't work with PhoenixMiner 5.0b and 4 GB AMD card. |
|
|
|
IMPORTANT! ETC is already at DAG epoch 350, so you must use PhoenixMiner 5.0b or later if you have 4 GB AMD cards. Additionally, here are some important tips for longest possible usage of 4 GB AMD cards with PhoenixMiner 5.0b: - If your rig is using Intel CPU, use the integrated graphics as primary display adapter. To do this, go to motherboard's BIOS setup and change the "Primary display adapter" to iGPU (or integrated GPU). Also, if you are using actual monitor or HDMI plug, put it in the motherboard video output.
- If you can't use integrated GPU, replace the primary GPU with one with 6 or 8 GB VRAM.
- Do not upgrade to a new AMD driver unless it is explicitly supported by PhoenixMiner. With 4 GB AMD cards, this will not only lower your hashrate but it will make impossible to mine when the DAG epoch is above 350.
- After the DAG epoch becomes more than 350, the optimal -gt value for the 4 GB AMD cards may change. So, we recommend to run auto-tune again after DAG epoch 350 to find the best GT values for the cards.
After extensive testing of AMD Windows drivers for the last two years or so, we identified two broad groups of drivers: - Good drivers. These are versions from 18.12.1.1 to 19.7.5 (inclusive), and from 19.12.2 to 20.4.2 (inclusive). These will allow you to mine until DAG epoch 372-373 and won't need restart of PhoenixMiner on each DAG epoch change.
- Not so good drivers. These are versions 18.1.1 to 18.10.1 (inclusive), and from 19.8.1 to 19.12.1 (inclusive). This will allow you to mine until DAG epoch 365-366 and will require restart of PhoenixMiner on each DAG epoch change (for these drivers this will be preformed automatically unless you have added -dagrestart 0 command-line option to explicitly disable the auto-restart).
- Drivers older than 18.1.1 were not tested for 4 GB DAG operation.
Under Linux all relatively recent drivers (i.e. last 24-36 months) allow mining until epoch 378-380 but there are much more driver bugs, so if you are happy with your current driver version, do not change it.
|
|
|
|
I'm having problem with dag350 and generating it... used -dagrestart 2 (and 1) but if the miner starts to generate this dag, the phoenix miner crashes... 4GB RX580, Win 10, 8 card rig, using the onboard video for windows 2D...
I'm using the Blockchain drivers (working no problems until now)... could the problem be with the driver?
Blockchain drivers are too old - we haven't tested with them but it is likely that the problem is caused by them. See this post for the recommended driver versions for 4 GB AMD cards: https://bitcointalk.org/index.php?topic=2647654.msg54502449#msg54502449hi
How to make sure that when reaching for example 62 degrees, the mining intensity decreases so as not to exceed the temperature threshold. What commands to put in a batch file. Driver version 19.7.5 mining 5.0b (my current settings, but on them the temperature continues to rise and above 62 degrees without reducing the intensity of mining -tt 61 -tstop 67 -tstart 50 -tmax 62 -fcm (0 or 2) -fanmin 50)
There is no such feature (reducing mining intensity to keep the temperature in check). You should use -tmax, which lowers the GPU core clocks when it reaches the target temperature. If it doesn't work, try a newer driver version (e.g. 2.4.2) and if still doesn't work, let us know what cards you are using. |
|
|
|
Miner didn't support new AMD 20.5.1 driver.
We are testing with the new driver and will release 5.0c soon that will support it. So far it seems that it behaves as the "good" drivers - i.e. allows mining until DAG epoch 373 on 4 GB cards. 20.4.2 had mem clock problems with navi.Pls someone recommend driver for both navi and polaris cards without anybug.19.11.3 no problems but not recommend PM devs.
Please note that in the latest drivers the memory clocks of Navi cards are shown as double the value from the previous drivers. If you have used - mclock 950 in the older drivers, in the latest driver you must use -mclock 1900. In order to check if this is the case, run the miner without -mclock but with -hstats 2 and see the nominal memory clocks then use the appropriate -mclock value. Hi @PhoenixMiner,
Which driver version you are recommend to use for GTX1080 on Windows 7?
We don't test on Windows 7 anymore but probably older driver will be better as neither 1080 nor Windows 7 are spring chickens One thing to be aware of is that some users have reported low speed (like 50% lower than normal) with Nvidia cards on Windows 7, which can only be fixed by increasing the physical RAM (i.e. the DIMM module(s) on the motherboard!) to at least 8 GB. Strangely enough, increasing the page file size does not help - apparently some kind of driver bug. There is no such problem on Windows 10. |
|
|
|
Here are some important tips for longest possible usage of 4 GB AMD cards with PhoenixMiner 5.0b: - If your rig is using Intel CPU, use the integrated graphics as primary display adapter. To do this, go to motherboard's BIOS setup and change the "Primary display adapter" to iGPU (or integrated GPU). Also, if you are using actual monitor or HDMI plug, put it in the motherboard video output.
- If you can't use integrated GPU, replace the primary GPU with one with 6 or 8 GB VRAM.
- Do not upgrade to a new AMD driver unless it is explicitly supported by PhoenixMiner. With 4 GB AMD cards, this will not only lower your hashrate but it will make impossible to mine when the DAG epoch is above 350.
- After the DAG epoch becomes more than 350, the optimal -gt value for the 4 GB AMD cards may change. So, we recommend to run auto-tune again after DAG epoch 350 to find the best GT values for the cards.
After extensive testing of AMD Windows drivers for the last two years or so, we identified two broad groups of drivers: - Good drivers. These are versions from 18.12.1.1 to 19.7.5 (inclusive), and from 19.12.2 to 20.4.2 (inclusive). These will allow you to mine until DAG epoch 372-373 and won't need restart of PhoenixMiner on each DAG epoch change.
- Not so good drivers. These are versions 18.1.1 to 18.10.1 (inclusive), and from 19.8.1 to 19.12.1 (inclusive). This will allow you to mine until DAG epoch 365-366 and will require restart of PhoenixMiner on each DAG epoch change (for these drivers this will be preformed automatically unless you have added -dagrestart 0 command-line option to explicitly disable the auto-restart).
- Drivers older than 18.1.1 were not tested for 4 GB DAG operation.
Under Linux all relatively recent drivers (i.e. last 24-36 months) allow mining until epoch 378-380 but there are much more driver bugs, so if you are happy with your current driver version, do not change it. |
|
|
|
Is -mclock not working bug fixed for Polarises?
-mclock is working for Polaris cards for all recent drivers (at least in the last year and half or so). There may be specific driver versions with problems but we are using both relatively old (18.2.1) and the latest driver and it works fine on both. Note that if the memory clocks are fixed in VBIOS when the BIOS was modded, this may prevent the miner from changing them. Remove the drivers with DDU, install newer driver (the latest 20.4.2 are OK so far), and see if the issue still remains. If so, send us a log file for the first several minutes of after the miner start (with private message, no need to post it here). Hello
on windows 7x64 you get an error
robinh00d_package_dag_fix driver
....
Unfortunately we don't test much on Windows 7 any more, especially with such old drivers. We will try to identify the problem and fix it in the next release if it is fixable (i.e. not something caused by a driver bug preventing the big DAG buffer allocation). |
|
|
|
PhoenixMiner 5.0b is officially released. You can find the download link and the checksums in the first post of this thread. Don't pay attention to the 'b' - it doesn't mean beta, it just means the second release build of this version. IMPORTANT! All owners of AMD cards with 4 GB VRAM must upgrade to PhoenixMiner 5.0b or later version to continue mining after DAG epoch 350 (i.e. about the start of June 2020 for ETC, and the middle of July 2020 for ETH). The new features in this release are: - Added support for mining with 4 GB AMD cards beyond the DAG epoch 350. Depending on the OS and driver versions, you will be able to use 4 GB AMD cards until epoch 372-373 under Windows, and 380 under Linux.
- Added new -dagrestart command-line option to work around the problems with DAG allocation on 4 GB AMD cards under some driver versions. See Readme.txt for more information.
- Added support for latest AMD drivers 20.4.2 under Windows and 20.10-1048554 under Linux
- Many other small improvements and fixes
|
|
|
|
|
Show Posts
