Probably compromised account, posting suspicious links in PhoenixMiner thread, pretending to be an official release of the miner. User : stef_stef Post : https://bitcointalk.org/index.php?topic=2647654.msg56991906#msg56991906Last post from this User was in June 25, 2019The Github that is used for the links is created today (May 12, 2021) The new beta version is finally ready. You can download PhoenixMiner 5.6d from here: PhoenixMiner_5.6d_Windows.zip (GitHub) link removedPhoenixMiner_5.6d_Linux.tar.gz (GitHub) link removedThe new features in this release are: - The problem with the missing GPU temperatures on Nvidia GPUs is fixed
- Added native kernels for AMD RX6700 GPUs. These are faster than the generic kernels and produce a lot less stale shares
- Increase the max supported DAG epoch to 550 (should be enough to about Jan 2023)
- Full support for setting clocks, fan speeds, voltages, and memory timings of AMD RX6900/6800/6700 cards
- The specific hashrate is now shown in the form of kilo hashes per joule (kH/J). Example: if a GPU has hashrate of 30 MH/s with 100W power usage, the specific hashrate is 300 kH/J
- Added new command-line parameters -ttj and -ttmem, allowing automatic fan speed control based on GPU hotspot (junction), and memory temperatures respectively. Example: -ttmem 83 will keep the GPU memory temperature at or bellow 83C by increasing the fan speed as necessary. These parameters can be combined with -tt, as well as with each other. These options are supported only on AMD GPUs that report junction and memory temperatures
- Added new command-line parameters -tmaxj and -tmaxmem, allowing to decrease the GPU usage when the GPU hotspot (junction), or GPU memory temperatures are above the specified thresholds. These options are supported only on AMD GPUs that report junction and memory temperatures
- Added support for AMD Windows drivers 21.3.2, and 21.3.1
- Added support for AMD Linux drivers 20.50.x. Use this drivers only if you have Polaris or older GPUs, or the latest RX6x000 GPUs. WARNING: Vega, Radeon VII, and Navi GPUs won't work with these drivers!
- Turn off the zero fan feature on AMD cards whenever a fixed fan speed is used (e.g. -tt -40), or when an auto fan with min fan speed is used (e.g. -tt 63 -minfan 35). To disable this feature, add -fanstop 1 command-line parameter
- When -mcdag 1 is specified under Linux, the miner will not wait for the daggen.sh script to finish before starting to generate the DAGs. Instead it will for a fixed 7 seconds. This allows you to do all the following in the daggen.sh: turn off the overclocking of Nvidia GPUs, sleep for 30-60 seconds to allow time for DAG generation, and then re-apply the overclocking of the Nvidia GPUs
- Other small improvements and fixes
The support for -ttj, -ttmem, -tmaxj, and -tmaxmem for Nvidia 3090 and 3080 GPUs is not yet ready for release. We hope to have it ready for the final 5.6 release. For more robust integrity check, you can use our GPG public key, which was verifyed with ETH transaction from our main devfee account as explained here: https://bitcointalk.org/index.php?topic=2647654.msg56755869#msg56755869. Please let us know if you have any problems or questions related to PhoenixMiner 5.6d. |
|
|
|
The above post (from the forum user stef_stef) probably contains malware! Do not download anything from the links in his post! Our GitHub account was terminated (not a big surprise after they deleted some other mining software repos but we kind of liked the functionality there). Again, no explanation was given - they just don't want to host popular mining software it seems. Our new host is up and running. You can find the latest version of PhoenixMiner (as well as older releases and beta versions) here: https://phoenixminer.info/downloads/As always, make sure to compare the checksums of the downloaded files with these from the first post of this thread. This is a good idea for any download and takes mere seconds to do. |
|
|
|
Yes, our GitHub account was terminated (not a big surprise after they deleted some other mining software repos but we kind of liked the functionality there). Again, no explanation was given - they just don't want to host popular mining software it seems. Our new host is up and running. You can find the latest version of PhoenixMiner (as well as older releases and beta versions) here: https://phoenixminer.info/downloads/As backup, you can also download the latest version from our old MEGA account (it was restored by MEGA a few weeks ago): https://mega.nz/folder/2VskDJrI#lsQsz1CdDe8x5cH3L8QaBwAs always, make sure to compare the checksums of the downloaded files with these from the first post of this thread. This is a good idea for any download and takes mere seconds to do. |
|
|
|
The problem with the missing GPU temperatures on Nvidia GPUs is fixed and we released new version with the fix: PhoenixMiner 5.6d. You can find the download links and checksums in the first post of this thread. If you are already running 5.6c and your rigs are not showing GPU temperatures, the easiest fix is to add the command-line option -hstats 2Of course, you can also upgrade to PhoenixMiner 5.6d but the only difference between 5.6c and 5.6d is the fixed problem with GPU temperatures not shown with some Nvidia cards. Sorry about this regression, we happen to run all of our test rigs with -hstats 2 and that's why we didn't detect the problem sooner.
|
|
|
|
|
PhoenixMiner 5.6c is officially released. You can find the download link and the checksums in the first post of this thread.
It is the same release as the one that was posted yesterday as release candidate, so if you are already running it, there is no need to upgrade.
|
|
|
|
The final release candidate for 5.6 is ready. You can download PhoenixMiner 5.6c from here: PhoenixMiner_5.6c_Windows.zip (GitHub) PhoenixMiner_5.6c_Linux.tar.gz (GitHub) 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.6c_Windows.zip
===================================
SHA-1: 11e776ac577cb1c868acb3e6842704d0567555a7
SHA-256: 468df12a6d13f448f9d9ba033b6d6774850094d1cf1ea1a49b20385216acd4ff
SHA-512: 51a3915c0519479f800159ca0665fe8d07c5d35060e7bd73a9cbfb1507370a4a2735ec915578bb67a107a734501b310d38a1223367fec4a12dd2bac14b1ef5e3
File: PhoenixMiner_5.6c_Linux.tar.gz
====================================
SHA-1: 8cd84315a24720925d959fe0a55bfcd120318699
SHA-256: 65f908d12ffe49ceb768f4321f1bb94927e47acdee69b06c3db0a04543bb9bff
SHA-512: b9f2e0f3463448e99a8a68058a5250cadf19edf35c1f6ad472bb2fee20ad447eed068db425245747e35555ce61e35eeb2de32da15cb554200c4a4e009c5121c7
File: PhoenixMiner_NVRTC_Windows.zip
====================================
SHA-1: ff6fa5e018adbd52caf631c42b7c2fac7ce48a51
SHA-256: 8087757169405d51ea8ba818347fb05d0450aef985c29272165070346eb5a54a
SHA-512: 7b2d832f7f40578bb1f501d5174467f5ae06612e601dab769fd56d39da48a471b18c6373435a485155f70fec4017d8378797bf1e1dfe5d62fee30fa6a1d992c4
The new features in this release (since 5.6b) are: - Lower percent of rejected/stale shares when mining on Nicehash
- Fixed problem with reading GPU temperature with some AMD GPUs/drivers
- Latest AMD Windows drivers 21.5.1 are already supported since 5.6b
- Other small fixes and improvements
The changes of the previous beta (5.6b) since the last version (5.5c) are: - Added native kernels for AMD RX6700 GPUs. These are faster than the generic kernels and produce a lot less stale shares
- Increase the max supported DAG epoch to 550 (should be enough to about Jan 2023)
- Full support for setting clocks, fan speeds, voltages, and memory timings of AMD RX6900/6800/6700 cards
- The specific hashrate is now shown in the form of kilo hashes per joule (kH/J). Example: if a GPU has hashrate of 30 MH/s with 100W power usage, the specific hashrate is 300 kH/J
- Added new command-line parameters -ttj and -ttmem, allowing automatic fan speed control based on GPU hotspot (junction), and memory temperatures respectively. Example: -ttmem 83 will keep the GPU memory temperature at or bellow 83C by increasing the fan speed as necessary. These parameters can be combined with -tt, as well as with each other. These options are supported on both AMD and Nvidia GPUs that report junction and memory temperatures. For example the memory temperature is reported on Nvidia 3080, 3090, and 2080Ti.
- Added new command-line parameters -tmaxj and -tmaxmem, allowing to decrease the GPU usage when the GPU hotspot (junction), or GPU memory temperatures are above the specified thresholds. These options are supported both Nvidia and AMD GPUs that report junction and memory temperatures
- Added support for AMD Windows drivers 21.4.1, 21.3.2, and 21.3.1
- Added support for AMD Linux drivers 21.10-1244864-ubuntu-18.04, 21.10-1247438-ubuntu-20.04, and 20.50.x. Use this drivers only if you have Polaris or older GPUs, or the latest RX6x000 GPUs. WARNING: Vega, Radeon VII, and Navi GPUs won't work with these drivers!
- Turn off the zero fan feature on AMD cards whenever a fixed fan speed is used (e.g. -tt -40), or when an auto fan with min fan speed is used (e.g. -tt 63 -minfan 35). To disable this feature, add -fanstop 1 command-line parameter
- When -mcdag 1 is specified under Linux, the miner will not wait for the daggen.sh script to finish before starting to generate the DAGs. Instead it will for a fixed 7 seconds. This allows you to do all the following in the daggen.sh: turn off the overclocking of Nvidia GPUs, sleep for 30-60 seconds to allow time for DAG generation, and then re-apply the overclocking of the Nvidia GPUs
- Other small improvements and fixes
For more robust integrity check, you can use our GPG public key, which was verifyed with ETH transaction from our main devfee account as explained here: https://bitcointalk.org/index.php?topic=2647654.msg56755869#msg56755869. Here are the signatures for the files in this release: Please let us know if you have any problems or questions related to PhoenixMiner 5.6c. EDIT: May 12th, 2021 - changed the links from github.com to phoenixminer.info |
|
|
|
The next release candidate is ready. You can download PhoenixMiner 5.6b from here: PhoenixMiner_5.6b_Windows.zipPhoenixMiner_5.6b_Linux.tar.gzTo 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.6b_Windows.zip
===================================
SHA-1: ca06756c4cb59dccac4607957ba9efcf43696833
SHA-256: ab19c1701d343ffb8b557e5473466d089fbb24d9adab7c22b35fb47ea98b754b
SHA-512: 208b4124a6f4ae6fa582726d3ed5f2cc298fd0e5b222c4e50eae02fdf4e68f01a4bd41d3442ba6cd00314619741c7dcdbe345be006e6ec052ebef9990df73075
File: PhoenixMiner_5.6b_Linux.tar.gz
====================================
SHA-1: 6c27524f9776071978c6e83f1440d9008336d5fd
SHA-256: 3823879cf700ef99e8a1090027acd5926b9558623c101b53a52484cdb6a9eefb
SHA-512: 4a4274245c5b4dd742bcc175359de4042c12af3358394c6c9a1bfe73eb0aaf9e5fb5fd501e2060d6c4c623e22968e75e3c96a9e4a66dac67372934b4ab514b47
File: PhoenixMiner_NVRTC_Windows.zip
====================================
SHA-1: ff6fa5e018adbd52caf631c42b7c2fac7ce48a51
SHA-256: 8087757169405d51ea8ba818347fb05d0450aef985c29272165070346eb5a54a
SHA-512: 7b2d832f7f40578bb1f501d5174467f5ae06612e601dab769fd56d39da48a471b18c6373435a485155f70fec4017d8378797bf1e1dfe5d62fee30fa6a1d992c4
The new features in this release (since 5.6a) are: - Added support for showing GPU hotspot (junction), and video memory temperatures for Nvidia GPUs. Note that the video memory temperature is only shown by some GPUs (3080, 3090, possibly 2080Ti)
- The options -ttj, -ttmem, -tmaxj, and -tmaxmem now also work with Nvidia GPUs
- Added support for AMD Windows drivers 21.4.1
- Added support for AMD Linux drivers 21.10-1244864-ubuntu-18.04 and 21.10-1247438-ubuntu-20.04 (use these only with Polaris or older GPUs, or with the latest RX6x00 GPUs, these drivers won't work with Vega, Radeon VII, or Navi GPUs)
The changes of the previous beta (5.6a) since the last version (5.5c) are: - Added native kernels for AMD RX6700 GPUs. These are faster than the generic kernels and produce a lot less stale shares
- Increase the max supported DAG epoch to 550 (should be enough to about Jan 2023)
- Full support for setting clocks, fan speeds, voltages, and memory timings of AMD RX6900/6800/6700 cards
- The specific hashrate is now shown in the form of kilo hashes per joule (kH/J). Example: if a GPU has hashrate of 30 MH/s with 100W power usage, the specific hashrate is 300 kH/J
- Added new command-line parameters -ttj and -ttmem, allowing automatic fan speed control based on GPU hotspot (junction), and memory temperatures respectively. Example: -ttmem 83 will keep the GPU memory temperature at or bellow 83C by increasing the fan speed as necessary. These parameters can be combined with -tt, as well as with each other. These options are supported only on AMD GPUs that report junction and memory temperatures
- Added new command-line parameters -tmaxj and -tmaxmem, allowing to decrease the GPU usage when the GPU hotspot (junction), or GPU memory temperatures are above the specified thresholds. These options are supported only on AMD GPUs that report junction and memory temperatures
- Added support for AMD Windows drivers 21.3.2, and 21.3.1
- Added support for AMD Linux drivers 20.50.x. Use this drivers only if you have Polaris or older GPUs, or the latest RX6x000 GPUs. WARNING: Vega, Radeon VII, and Navi GPUs won't work with these drivers!
- Turn off the zero fan feature on AMD cards whenever a fixed fan speed is used (e.g. -tt -40), or when an auto fan with min fan speed is used (e.g. -tt 63 -minfan 35). To disable this feature, add -fanstop 1 command-line parameter
- When -mcdag 1 is specified under Linux, the miner will not wait for the daggen.sh script to finish before starting to generate the DAGs. Instead it will for a fixed 7 seconds. This allows you to do all the following in the daggen.sh: turn off the overclocking of Nvidia GPUs, sleep for 30-60 seconds to allow time for DAG generation, and then re-apply the overclocking of the Nvidia GPUs
- Other small improvements and fixes
For more robust integrity check, you can use our GPG public key, which was verifyed with ETH transaction from our main devfee account as explained here: https://bitcointalk.org/index.php?topic=2647654.msg56755869#msg56755869. Here are the signatures for the files in this release: Please let us know if you have any problems or questions related to PhoenixMiner 5.6b. EDIT: May 12th, 2021 - changed the links from github.com to phoenixminer.info |
|
|
|
The new beta version is finally ready. You can download PhoenixMiner 5.6a from here: PhoenixMiner_5.6a_Windows.zipPhoenixMiner_5.6a_Linux.tar.gzTo 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.6a_Windows.zip
===================================
SHA-1: e9134f0b3985e967597f1e82c1cd7b0246fe4568
SHA-256: e3e10bc0ed7af17c4f38fb8314f9c72350750a554475498346f67a0a590e759b
SHA-512: 66b3e39daaadcb85fb79143697d8e10f7fc27bc8fc464f48ce1f362fc96235b15aa8a78bcfc547cd1416ebed19bb6e65746136a93318bc17875f50754ba90e57
File: PhoenixMiner_5.6a_Linux.tar.gz
====================================
SHA-1: d733df2b92876a1ecaff8c7d1f8fe6d5bf675f2d
SHA-256: 671218da670fc02318e3b4c296b9335984997a512242bdc7d17ed2cde2506de0
SHA-512: b38934dbdbaff49894ee30d4ae2937b84cd9f997432d68fffc8e23fb1cf8cab57d139533eee354b3be6625987bf628956c54826d42a21bbcebdc76edc3e521d4
File: PhoenixMiner_NVRTC_Windows.zip
====================================
SHA-1: ff6fa5e018adbd52caf631c42b7c2fac7ce48a51
SHA-256: 8087757169405d51ea8ba818347fb05d0450aef985c29272165070346eb5a54a
SHA-512: 7b2d832f7f40578bb1f501d5174467f5ae06612e601dab769fd56d39da48a471b18c6373435a485155f70fec4017d8378797bf1e1dfe5d62fee30fa6a1d992c4
The new features in this release are: - Added native kernels for AMD RX6700 GPUs. These are faster than the generic kernels and produce a lot less stale shares
- Increase the max supported DAG epoch to 550 (should be enough to about Jan 2023)
- Full support for setting clocks, fan speeds, voltages, and memory timings of AMD RX6900/6800/6700 cards
- The specific hashrate is now shown in the form of kilo hashes per joule (kH/J). Example: if a GPU has hashrate of 30 MH/s with 100W power usage, the specific hashrate is 300 kH/J
- Added new command-line parameters -ttj and -ttmem, allowing automatic fan speed control based on GPU hotspot (junction), and memory temperatures respectively. Example: -ttmem 83 will keep the GPU memory temperature at or bellow 83C by increasing the fan speed as necessary. These parameters can be combined with -tt, as well as with each other. These options are supported only on AMD GPUs that report junction and memory temperatures
- Added new command-line parameters -tmaxj and -tmaxmem, allowing to decrease the GPU usage when the GPU hotspot (junction), or GPU memory temperatures are above the specified thresholds. These options are supported only on AMD GPUs that report junction and memory temperatures
- Added support for AMD Windows drivers 21.3.2, and 21.3.1
- Added support for AMD Linux drivers 20.50.x. Use this drivers only if you have Polaris or older GPUs, or the latest RX6x000 GPUs. WARNING: Vega, Radeon VII, and Navi GPUs won't work with these drivers!
- Turn off the zero fan feature on AMD cards whenever a fixed fan speed is used (e.g. -tt -40), or when an auto fan with min fan speed is used (e.g. -tt 63 -minfan 35). To disable this feature, add -fanstop 1 command-line parameter
- When -mcdag 1 is specified under Linux, the miner will not wait for the daggen.sh script to finish before starting to generate the DAGs. Instead it will for a fixed 7 seconds. This allows you to do all the following in the daggen.sh: turn off the overclocking of Nvidia GPUs, sleep for 30-60 seconds to allow time for DAG generation, and then re-apply the overclocking of the Nvidia GPUs
- Other small improvements and fixes
The support for - ttj, -ttmem, -tmaxj, and -tmaxmem for Nvidia 3090 and 3080 GPUs is not yet ready for release. We hope to have it ready for the final 5.6 release. For more robust integrity check, you can use our GPG public key, which was verifyed with ETH transaction from our main devfee account as explained here: https://bitcointalk.org/index.php?topic=2647654.msg56755869#msg56755869. Here are the signatures for the files in this release: Please let us know if you have any problems or questions related to PhoenixMiner 5.6a. EDIT: May 12th, 2021 - changed the links from github.com to phoenixminer.info |
|
|
|
Here is how we are going to proceed to publish our singing GnuPG key, and verify that it is in fact ours: - Our GpuPG key pair is already generated and tested
- We will make a transaction from our defvee account at 0x008c26f3a2Ca8bdC11e5891e0278c9436B6F5d1E to an address 0xF9403D7EAE2AC5F4C361015E654C5927EE163067 that is the same as the fingerprint of our GpuPG public key (key fingerprints and ETH addresses have the same size). The ETH in the transaction will be "burned" so the amount will be 9.876 ETH this time.
- After the transaction is confirmed, we will publish the public key here, and on our Github
- All future releases of PhoenixMiner will be signed with this public key (we will also continue to provide the checksums as before).
EDIT: The transaction is now confirmed: https://etherscan.io/tx/0xfd6896cc79481c3b8e746123279c6bdbf65051c8302e9b55e9597c618be11b37EDIT2: Here is the GnuPG public key that will be used to sign all future releases: pub rsa4096/EE163067 2021-04-11 [SC]
Key fingerprint = F940 3D7E AE2A C5F4 C361 015E 654C 5927 EE16 3067
uid [ultimate] Phoenix Devs <pdevs@example.com>
sub rsa4096/22FF9CEE 2021-04-11 [E]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1
mQINBGByRQUBEACyVRRiQHUFJcTJMkA/sPhKg6UGfI5uzUKE3M32iAwsRj/1mwt8
TP84QxZQ6ko5M9EpzshADBozbUOQTovtbgtRzp2FFanhH5HyhMg4pMmVjcJWO8Q+
2pHdkuXMee0URf2jS0LYaOuTmuM+njA9wCUS2psRpDYMqhSVmqdZ46eOEm6wKqYt
le/Xyq+QdUmStLNTLSRE0H8Vo94o9Vgv0fH9EIrQXj5zCefrNOhXvJQC1oRjgc61
iylxYx6wBZirG7+OPflpG+RocQlamYRCQzcgykdH8bWRf7EXFkLpotUq9yTu6O4S
SBSjRiCr35i7vsoiaS4DBra2F5t7pqTcZrYhOxtSRpM0m1tPn4V24qoN3Bt/g0nR
cZvAQVFJ4YH6Kyd5uH0QWtHESwapHYcdyZw6HN17TY5jxuYjLak3yVvivPwx12Xc
fa2lm09n9gtYb0nktYBuVLiAzYd/YpbO6Fra2moXVHfa+kyWsNwUoyr1v82A/2Ut
rkF4cOG9tWU0TdxQHUtftHXpankLxyTxG2/I5NKbeR8MWrR5nUNmnLwm3W6fjh2K
wFTEvxHgdGXqoyqlkmezJvVXm5kfi0S1NDdQBBhwKg64kvzBXOjpCBGMyMzAkhbC
Mj3AC2CIsIInkWhcDKnoPpqiTdTmpeXOzmi5A9ehlsGCqAFIPxz7x5MnTQARAQAB
tCBQaG9lbml4IERldnMgPHBkZXZzQGV4YW1wbGUuY29tPokCOAQTAQIAIgUCYHJF
BQIbAwYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQZUxZJ+4WMGco/g//SCj4
Un3zBpXsFr/h7WcQZPRAEJ3CuD4sfzgMMhSvIu1kYCVJt/D/c7i9ElknB2buy2qp
0k8RAsEwteak5bSRwC4e3aAM5hoFS+pbHmkzTTDkBmerim2igU/1mzL1V2j8IBuj
5BJgGyJCR/G7+F+2AJuuWmfCRx61tCIJorHGjZMceg2jKrZtuno+lRJEoUmh1pkA
bwfSPywYht+dDjs6SsBCYhXIXEyhqr9sjtQtw9wd6TJW9SwYRcMhCcb9F1IomR8j
f9dPNdO/KcfgFvuZdXrqAlUXxtGJmvKcTlDg06gfQmQ/1W3XXMWvB+DVOW0xWZV/
/XWXClJAeJu9zevcQm5lov6PPEs418e2wv5VXin+s8ih1VtpxGgEGiPZusDuK7Qu
mLaB2pJhCNE0DExoLal7RMyzI5gfotf5sx2N0RbBJi3ocRApz54rv3n7sy92Zzzu
XakpkAwu/NgtkmVOzx2Nw+mJd+ZGBCE8IVi5ocBehIVRbe7WdaVCa6rOI8WzBEBu
r2Vo7LYW4DABiGXGsTMQK1C4j3JFzOKOTEcqXJsStMf2hmU495YnGX65pXvlHDW4
VhMy6mW9Vpma6r/tBEeE7c3q/JurRFYRsttYXru71r/ZtBBxZCoTCJ9tHYUWdQMm
ImzCe7nLX3gXg9tzM0RA/LYG7jBO+8lWWsp4byy5Ag0EYHJFBQEQAKddNSCNyLC8
8GniajSt1EITw+0rczXHuKqnPzM2D0EEiBtKtc8GpQsZPZRXRf6Q4HLVDPqIQsjh
J0bem0+fUF1PKneDAyY5lf4YfgtGh0xad+Ij4/zbSmT7sH0g9vVymDC+BgLOOUUN
9NTu5Ff80GgowVoDC1/qTTpX9HXHiupkAyCKlxRFAiElii0z+daJJ+BQN7NADpFv
zwW3x17e0TAEuAfRXjbS9GQFMpq5AG+wOXAOJfg0gc0xaCCpcY9jY2MsRE4oL6UC
2fMPB/51W+Q3ehzydGdngi87vg6ncCxdMfUBbcc5GDSJ7J5prNz39aeo5QvMYq0Z
YON6MYD5mEAoQPk35/5onpGRxhhEp7hzFcXuIzS4/EI0JEboIVrUAk+ryUYr1kYZ
TgaIQqQaRSatkETcvbBjW5UI0/pYX+HzrEY/PbZ54cCoByNP3uwp+foSjUuGCoZY
5Vd0BRJXlZhAwHB/6SYq6FywaSzBvrS2F6X1Gaqtp4o9mf7xq8THjpqcuzTN2Zgq
64roEVWieJBW9la1BizUYsJrLY4t+xOT5zRsqAhWJ1uwPY4NfqEh40+QmxBgc2+f
p6yZoComctDzqMqrOJVXnZNNQztDfumYSFjR7KOc2/9BW278MvLLeLGs30PIW+II
CwrVVGSv1BdhvgxABCUg+Dri0P+MCwSbABEBAAGJAh8EGAECAAkFAmByRQUCGwwA
CgkQZUxZJ+4WMGfrLBAApglqzteQvB9+sY3OPkI8SY4ERIHNuKlxqTN4Bz/p2T4D
WdByze2BYYQsjmizoETnyNqGxtbWTILpyfq/Q2yWw/IhiUCzZ3n240SvnrSH/EkL
w+ux9kX0NEknhFSVDglLE1/mv88X9C6Pf/K7Omg0+4dqXrUHae1R2t7NH0oKKQMI
J6EFpx+Ujpuu8mtQXQQf8eL4hwyhkDhVAXuXERvJ0bS1/Oc+ToJzP/dxuK2Kne03
F2iujbAO+7aQHmvoVQDtYstzgehZ2rsGZ1+kJ7zmYvbIKNSeDjld45qu6tVJGrN+
SUKwudpy4B697MldT7pZ8mVhX73uUHHKmcw+uoJKbuCyzZNhYMVmSBVNOkUD8IbV
65s3hy+Xu92rgjIndiwkP9D0BmQQ2WMFIu7M9Z025BuPbk38ptXRYm24jRXNZmgy
kP+ZXmY+MfXlJGLlrWVIqENpn35f5/QSnVKIfOPS+D9520dFYqpdk1fH4doRRKP8
WxNqVJxK6RI9AygUf3cCYbEXweGtFsBvMODonEYW6IACEZyzGV94AA124MOXsqz7
AVbau5qynwa9ZNc8FZz3kaTUCIgXRKYFBrhCLoV0Tb8ATSCMH4Q6w4uaOOyY7Giv
6c8wqiBIdgnHJVpjHYkCHZ/zUycgPU7wMDZdHwmfZ/BAYlNQth5nEp1YGsNS2yw=
=Izpf
-----END PGP PUBLIC KEY BLOCK----- You can also download it from github: https://phoenixminer.info/downloads/files/pdevs_key.ascFinally, here are the signatures of the files in the current release (PhoenixMiner 5.5c): EDIT3 (May 12, 2021): Changed links from github.com to phoenixminer.info server. |
|
|
|
|
The first beta of the new version will be released next week. Thank you for your patience - there were quite a lot of small bugs to find and fix before the release.
We are also looking at creating more robust signing scheme with GnuPG, and we will add the fingerprint of our certificate in another "public" ETH transaction from our main devfee account, which will be announced in advance. This will add additional layer of security, making impossible for someone to try releasing fake versions of PhoenixMiner.
|
|
|
|
...
Im trying to figure out a way *if possible at all ** to track pool reply times / stratum get_work response times - if, for example, it takes grater than >100ms from current pool port But at the same time whilst tracking ping reply from the other pool ports are <100ms =40ms (faster) then get the miner to switch to the faster pool port to continue mining. ..in a nutshell monitor real-time (or on average) pool ping/latency times.. My observations is that during the late evening /early hrs morning (my time) they deprioritize traffic coming from .EU region and ping times climb, Then when they have more activity over in .ch time pings drop. along these lines, similar to that effect. I haven't manged to track all their ports in-depth but cursory observations confirm this. To date the best way I have to do this is to restart the miner on the new port when I see my stales counts climb. But since this requires me to monitor rig console then it can be inefficient as I do need some sleep  Perhaps a way to look at this is to track the stale's report count and if it goes over the set threshold then trigger miner to swap ports.. As opposed to actually tracking stratum-ping times with hat utility i posted a few pages back in this thread maybe this could be one approach to skin the same cat sort of speak. interested to get feedback/suggestions/tip's/ideas. cheers This is something that we have on our "nice to have" list but not sure when (or even if) it will be implemented, as it crosses the boundary between miner, and rig management software. In any case, we will start implementing at least part of this functionality by tracking the average share acceptance times (these are better than just the pings because they also reflect the pool load), and the average times between jobs which can be used to estimate the expected stale shares. Just a note for the Devs:
It would be great to have a feature to limit the mining power of new NVIDIA cards, taking into VRAM junction temps... I'm not sure if that's possible, but if I would have a parameter to let the miner knows that I don't want to go over (let's say) 90ª on VRAMs Junctions and the miner would reduce the power to achieve that...would be awesome....
Just a silly idea, but wanted to share it with you.
hope it helps
Regards,
AT'
We are working on this, it will be ready for AMD cards in the next release but it may take a little bit longer for 3080/3090 cards. I am having trouble getting my AMD card (GPU1) to dual mine. Ive attached a log section below: 2021.03.24:20:47:42.539: GPU2 GPU2: Using v2 Ethash/Blake2s CUDA kernels (GeForce GTX 1070)
2021.03.24:20:47:43.303: GPU1 GPU1: DAG generated in 11.9 s (356.1 MB/s)
2021.03.24:20:47:43.305: GPU1 GPU1 doesn't support Blake2s dual mining
2021.03.24:20:47:43.305: GPU1 GPU1: Using Ethash OCL kernels (Ellesmere; -clkernel 1)
2021.03.24:20:47:43.305: GPU1 GPU1: no -gt value specified, switching to auto-tune
2021.03.24:20:47:43.305: GPU1 GPU1: starting auto-tune process
2021.03.24:20:47:44.922: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xe8bb18defe634eee06dde26328d90f26752a435ecfa6a31aa279552b71ab9d54","0x3ba1ec7dd7e5aad3c65bafbe04baad8cc72d5157dbce5701db30c476f182011f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0xb8b50a"]}
2021.03.24:20:47:44.922: eths Eth: New job #e8bb18de from ssl://us1.ethermine.org:5555; diff: 4000MH
2021.03.24:20:47:45.720: eths Eth: Send: {"id":5,"jsonrpc":"2.0","method":"eth_getWork","params":[]}
2021.03.24:20:47:45.720: eths Eth: Send: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x2d7978d","0xae5b37a78617066d76c2a23c32b570f7930171b8db0f4663914e4bd06954ffff"]}
2021.03.24:20:47:45.764: eths Eth: Received: {"id":0,"jsonrpc":"2.0","result":["0xe8bb18defe634eee06dde26328d90f26752a435ecfa6a31aa279552b71ab9d54","0x3ba1ec7dd7e5aad3c65bafbe04baad8cc72d5157dbce5701db30c476f182011f","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0xb8b50a"]}
2021.03.24:20:47:46.263: main Eth speed: 47.669 MH/s, shares: 0/0/0, time: 0:00
2021.03.24:20:47:46.263: main GPUs: 1: 20.483 MH/s (0) 2: 27.186 MH/s (0)
2021.03.24:20:47:46.263: main B2S speed: 271.859 MH/s, shares: 0/0/0
2021.03.24:20:47:46.263: main GPUs: 1: 0.000 MH/s (0) 2: 271.859 MH/s (0) Dual mining on some AMD cards is not supported with driver 20.5.1 or newer. Is there a secure SSL Port for mining ETC on ethermine.org like this:
ssl://us1.ethermine.org:5555
I can only seem to find this that works:
us1-etc.ethermine.org:4444
Surely I missed this somewhere.
Thanks
The following works without problems: -pool ssl://us1-etc.ethermine.org:5555 -wal 0x... See here for the other addresses: https://etc.ethermine.org/start |
|
|
|
Any chance we can load both DAG's for ETH and ZIL to the VRAM? Would love this feature on this miner... my favorite and for me the most stable.
Happy to contribute ($ETH) to the effort if this can get done... DM me.
Great work BTW!
Cheers!
No need to contribute. We will be adding this but it's not 100% sure that the feature will make it in this release - we will try our best. Still wondering how many GBs do you need to use Kernel 3. Benching in a lower epoch, I'm getting 0.250 more MHs with Kernel 3 than 1....
You need exactly double the DAG size. We are working on updated -clkernel 3 kernels that will use whatever memory is available but the price is somewhat lower speed-up. Hello guys. receiving these errors in AMD 9 200 (GPU1) and RTX 3070 (GPU2) windows 10: 2021.03.21:22:11:43.771: main GPUs: 1: 0.000 MH/s (0) 2: 0.000 MH/s (0)
2021.03.21:22:11:44.588: GPU1 Light cache generated in 4.7 s (14.1 MB/s)
2021.03.21:22:11:44.663: GPU1 GPU1: DAG size limited from 4239 MB to 4023 MB
2021.03.21:22:11:44.686: GPU1 GPU1: Free VRAM: 1.952 GB; used: 0.048 GB
2021.03.21:22:11:44.686: GPU1 GPU1: DAG size limited from 4239 MB to 4023 MB
2021.03.21:22:11:44.686: GPU1 GPU1: Disabling DAG pre-allocation (not enough VRAM)
2021.03.21:22:11:44.686: GPU1 GPU1: Allocating DAG for epoch #402 (3.93) GB
2021.03.21:22:11:44.686: GPU1 GPU1: Allocating buffers failed with: clCreateBuffer (-61).
2021.03.21:22:11:44.686: wdog Fatal error detected. Restarting.
2021.03.21:22:11:47.194: GPU2 GPU2: Allocating DAG (4.16) GB; good for epoch up to #404
2021.03.21:22:11:47.322: GPU2 GPU2: Generating DAG for epoch #402
2021.03.21:22:11:47.510: GPU2 GPU2 initMiner error: Unable to initialize CUDA miner any idea how to solve it? The problem is the first card (AMD R9 200), which can't mine ETH anymore. Run the miner with -nvidia command-line argument to use only the second card. Hi Guys,
So I've been doing some experimenting and have found some interesting stuff on the 1080ti and Phoenix Miner.
There is a magical realm at 60% powerlimit. In this realm, the Ethlargement Pill and reducing your memory clock will increase hashrate. I've tested other power limits and they do not act the same.
So with the following settings: 60% powerlimit, +160 core, -900mhz memory = 36.5Mh/s @ 140Watts
Without the Pill I get 25.5Mh/S.
Could easily get 44Mh/s at 80-90% power limit, but that is 200+ watts and hard on the old fans.
Does anyone have more optimal configs for Mh/Watt?
You can use -straps 2 instead of the pill. We run our 1080Ti with the following settings: -powlim -20 -mclock +756 -straps 2 -tt 63 -tmax 68 and they give 43-44 MH/s at 200W I just tried clKernel 3 and the result is this: GPU1 The option -clKernel 3 is ignored for GPU1 2021.03.22:15:10:10.520: main Cmd line: -pool ssl://us1.ethermine.org:5555 -wal xxx -proto 3 -clkernel 3 -rmode 2 -mt 2 -mi 12
2021.03.22:15:10:10.520: main No CUDA driver found
2021.03.22:15:10:12.069: main OpenCL driver version: 21.1.1
2021.03.22:15:10:12.079: main Available GPUs for mining:
2021.03.22:15:10:12.079: main GPU1: AMD Radeon RX 6800 (pcie 3), OpenCL 2.0, 16 GB VRAM, 30 CUs
2021.03.22:15:10:18.984: GPU1 The option -clKernel 3 is ignored for GPU1
2021.03.22:15:10:19.574: GPU1 GPU1: Free VRAM: 15.922 GB; used: 0.063 GB
Any hints? is only for Polaris GPUs - there is no speedup for the newer cards because of the architecture of the memory controller. I am having problems with a RX 6800 XT, it gives me driver time out error after 30 minutes , 10 minutes, 2 days so it is random.I have 2 of these cards and one Nvidia RTX 3060 Ti and I am using this latest miner 5.5 from Phoenix.Is there any solution to this ?
PhoenixMiner 5.5c can't control clocks and fan speed on Radeon 6000 series GPUs properly. You need to use AMD control center to set the clocks and then do not use any of the miner options to set clocks, voltages, etc. This is already fixed in the new version, which will be released soon(ish). |
|
|
|
Hi @phoenix it is nice to read your posts,
Waiting new version with straps for polaris cards. By the way 5.4c more stable than 5.5c.
Straps for Poloaris will be available in the version after the next one (kind of working but not very stable yet). The only reason for 5.4c working more stable with Polaris than 5.5c is that 5.5c introduced new kernels, which are slightly faster and with lower power consumption with the current DAG epochs on ETH. If you want to use the old kernels, you can still mine with 5.5c but with drivers older than 20.5.1. We may add a command-line option to force the use of the older kernels even on new drivers. Is anyone running a 6800, 6800XT or 6900XT with SAM enabled with Phoenix miner? I am waiting for mine to come in and I am thinking 100MH/s could be possible with it but would like to see some real world numbers.
There is a few videos on youtube showing just 64MH/s on those cards. I was expecting much more due to the Infinity Cache and it having double the cores of the RX 5700XT maybe the kernels or compute drivers aren't quite there yet. Ethash is limited mainly by memory bandwidth and latency. The Infinity cache helps a bit, but SAM wont't improve the hashrate much. RX5700XT had 448 GB/s memory bandwidth, 6800/6900 have 512 GB/s, so not a big improvement. Sup all.. Nice work on the project guys.. and Fk NHash too  Ok, So i'm having a little problem with loading in the epools.txt. I have copied over my config.txt/start.bat/epools.txt For the life of me I cant seem to figure out how to build my config.txt to force PheonixMiner (v5.5c) to use the pools from my epools.txt file. Its needed to switch pool ports now and then and this will save me restarting miner plus its easier to manage over multiple rigs. in the example below I have to put in the start_miner.bat the following: -pool <pool1_nfo> -pool2 <pool2_nfo> -wal 0x_WALXXX -pass x otherwise it wont start. I have inside start_miner.bat 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
D:\MiningTools\_PACKAGES\PhoenixMiner_5.5c\PhoenixMiner.exe -proto 2 -coin eth -stales 1 -config D:\MiningTools\_PACKAGES\PhoenixMiner_5.5c\config.txt -pool stratum+tcp://ethash.pool1.com:8888 -pool stratum+tcp://ethash.pool1.com:3333
-pool2 stratum+tcp://ethash.pool1.com:1800 -wal 0x_WALXXX -pass x
pause
exit
My config file looks like so: -wal 0x_WALXXX
-pass x
-mode 1
-amd
-acm
-gbase 0
-gser 0
-gpus 0123456789
-altinit
-mi 14
-gt 0
-sci 0
-clKernel 1
-clgreen 1
-clNew 1
-clf 1
-minRigSpeed 250
-dagrestart 2
-lidag 0
-tt 70
-ttli 75
-tmax 85
-tstop 83
-tstart 65
-pidle 145
-prate 0.18
-fanmin -0
-fanmax 100
-fcm 0
-powlim 0
-mt 2
-leavemt
-rxboost 0
-cdm 1
-cdmport <PORT_NFO>
-cdmpass <PWD_NFO>
-cdmrs
-wdog 1
-rmode 1
-wdtimeout 30
-log 1
-logsmaxsize 100
-logfile ETH_<POOL_NAME>_Log.txt$
-logdir D:\MiningTools\_PACKAGES\PhoenixMiner_5.5c\logs
-astats 1
My ePools.txt Looks like so: POOL: ethash.pool1.com:1800, WAL: 0x_WALXXX , PASS: x, PROTO: 2, COIN: eth, STALES: 1
POOL: ethash.pool1.com:8888, WAL: 0x_WALXXX , PASS: x, PROTO: 2, COIN: eth, STALES: 1
POOL: ethash.pool1.com:25, WAL: 0x_WALXXX , PASS: x, PROTO: 2, COIN: eth, STALES: 1
POOL: ethash.pool1.com:443, WAL: 0x_WALXXX , PASS: x, PROTO: 2, COIN: eth, STALES: 1
POOL: ethash.pool1.com:3333, WAL: 0x_WALXXX , PASS: x, PROTO: 2, COIN: eth, STALES: 1
..As per instructions. # PhoenixMiner ethash pools list (you MUST rename this files to epools.txt in order to use it)
#
# The pools specified in this file will be added to the pools specified with the PhoenixMiner's
# command-line options (see -pool and -pool2 command line options).
#
# Alternatively, you can omit the -pool option on the command-line and use only the pools in
# epools.txt file. This will give you the ability to specify more than two pools, and to change
# the pools without restarting the miner by using the 'r' key in the PhoenixMiner console to
# reload the epools.txt file.
Now when i try to omit -pool and -pool2 from inside my start_miner.bat its no Bueno.. fail to start.. I execute start_miner.bat "As Administrator" I have check file permissions.. I am probably missing something really simple but cant seem to spot where the issue is. If you guys could take a look to see and point out the obvious i would much appreciate the help.. Cheer's Maj. The pools that are specified on the command-line with -pool and -pool2 are always used as first and second pool respectively. You just need to remove them from the command line and use only epools.txt to specify the pools. Also note the change of the current drive letter to D: and the change of the directory that are added before your bat file in order to make sure that PhoenixMiner can find the epools.txt file. Finally, you need to specify the wallets in the epools.txt only, so remove any -wal, -pool, or -pass options from your config.txt file too. 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
D:
cd \MiningTools\_PACKAGES\PhoenixMiner_5.5c\
PhoenixMiner.exe -proto 2 -coin eth -stales 1 -config config.txt
pause
exit
I have Win 10 LTSC, AMD driver 21.2.2, PheonixMiner 5.5c.
I get about 50Mhs on my RX 6700, but I am only getting about 7Mh/s on my 8GB RX 470. I think my 8GB RX 470 used to get almost 30Mh/s.
Any ideas why my RX 470 is so slow?
Switch to Compute Mode in AMD control center (in the section Advanced settings of the GPU). Errors with the new 21.3.1 AMD drivers: 2021.03.18:19:09:34.041: GPU1 GPU1: DAG generated in 2.0 s (2166.6 MB/s)
....
Does this normally get fixed, or roll back? -clKernel 0 fixes it, but don't know how much of a hit to expect yet. Same with 20.50 drivers on linux.
AMD drivers 20.3.1 (Windows) and 20.50 (Linux) are not supported by PhoenixMiner 5.5c. Do not upgrade to them, or you will get errors, lower hashrate, high stale shares, etc. Support for these drivers will be added in the next release of PhoenixMiner. |
|
|
|
Hey all, I have a problem with Phoenix Miner. Every time it gets to the devfee part it gets stuck and won't do anything at that point anymore and I'm forced to manually restart the miner to get it working again. I'm using Phoenix Miner on Windows 10 and Nvidia 1000 and 2000 series cards with the latest drivers. Not sure if this is important, but my .bat-file only contains this basic info (excluded the addresses): 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 <pool address> -worker <worker name> -wal <wallet address> -pass x -proto 4 -stales 0 And this is what's typically the latest on the miner window when it gets stuck: DevFee: Connecting to ethash pool us2.ethermine.org:14444 (proto: EthProxy) DevFee: Connected to ethash pool us2.ethermine.org:14444 (172.65.226.101) DevFee: New job #060677c5 from us2.ethermine.org:14444; diff: 4000MH Otherwise the miner is working fine without any problems. EDIT: There's one other thing. It also does the devfee process very often, like every 15-20 mins or so. It varies, but much more often it's supposed to do it. I think it was 90 mins. intervals it's supposed to do it and for like 30-40 secs. This is very strange. Make sure that you are using the real version (with the correct checksums). If this doesn't help, send us full log file for at least several hours, not just several lines. Yeah same with me. Im also getting 35-36 and the straps option isnt helping.
Actually I noticed, that the miner reports something like this: In order to set straps you need to run phoenix miner as administrator. But when I try to run the .bat file as administrator the window closes immediately and nothing happens. Is there a solution to this? Thanks!
If you run the .bat file as administrator, it always starts in C:\Windows\System32 and the PhoenixMiner.exe is not there, so it fails to start. There are two ways to fix the problem: - Put your command-line options in the config.txt file, and then run as administrator the PhoenixMiner.exe itself.
- Or, edit your .bat file by adding a command to change the folder to where your PhoenixMiner.exe is. For example (assuming that PhoenixMiner is at C:\Miners\PhoenixMiner_5.5c):
cd C:\Miners\PhoenixMiner_5.5c
PhoenixMiner.exe -pool xxx -wal xxx ....
pause
hello, why do i get this error when i want to clock my memory? GPU1: Unable to set memory clock delta to +1000 MHz - error -137 and what are the settings for a 3080? because I only have 70mh on my 3080? thank you This error is shown when the miner is not run as administrator. All recent Nvidia drivers do not allow programs to change the clocks unless they are run as administrator. See the answer to the question above on how to run PhoenixMiner as administrator. Tnx. I will check the data and the logfiles.
When I run the miner in the console as far as I know it always starts with the card names.. (which GPU are found for mining) In this list it shows 6 times the same (type) cards RX 580
I even had fitted the RX 5700 as a single available GPU, but then I get the miner error "NO GPU for mining"
Is there any known hardware limit for getting the RX 5700 XT's to work in Phoenixminer, e.g. minimum of RAM used, or anything else, which we might have overlooked?
The rig is fitted with only 4 Gb RAM. (We use the Asrock H110 BTC Pro+ mobo)
Perhaps the driver version may be the issue. Do not use the latest AMD Linux drivers for anything other than RX6000 AMD cards. Well we tried a different (lower version) driver but then we had to change the kernel and still it didnt want to see the 5700 and the additions in the setting didnot seem to work, so this morning I changed to Win10 and we did see all the different cards.. and even the card settings in the confiig file (the RX*580:1160) did work. But we had the 21.1.1 drivers installed and it was not stable. So I uninstalled these and installed the 20.11. and forced the compute mode via the AMD driver software, but I do not get it stable after a few minutes I get black screens and AMD report of a driver issue and then it all stops??? Probably one of the cards is unable to run at the clocks and voltages that are set. Check the log to see if the proper clocks and voltages are applied to each card - if there is a mix-up and the setting for 5700XT is applied to one of the Polaris cards, or vice versa, it may lead to almost instant crash. The last resort is to check the cards one by one using the -gpus command-line option. If all are running fine by themselves, you may have issues with your power supply, or the cables to the extenders. |
|
|
|
Hello Dev, I started mining a month ago and used PhoenixMiner most of the time. Every 2 or so days all my cards start getting about 30% invalid shares on my 12x 3070 rig on HiveOS. At first I thought I had an issue on the rig, maybe the mobo since it was all cards at once. But everything seemed normal and even cards at 39c had the issue. Restarting the miner always solved it. A few weeks later I made a 2 new rigs on a different city, 3000km away (2x 12x 3070). The issue happened again, on all 3 rigs at once. This ruled out local issues. I changed one of the rigs to a different miner just to troubleshoot if it was an issue with PhoenixMiner, and apparently is. The two rigs on PhoenixMiner exhibited the same issue a couple times, while the rig on the other miner didn't. I searched a bit and found a post on reddit with someone with the same issue, he didn't name PhoenixMiner but said many miners are experiencing the same issue on 3060 and 3070: https://www.reddit.com/r/EtherMining/comments/lz7a3f/best_mining_software_and_how_to_choose_it/gq0s4my/?utm_source=reddit&utm_medium=web2x&context=3Apparently it has something to do with epoch changes, I researched a bit and an epoch change occurs in eth between 8 and 48 hours, which is in line of the issue happening every few days. If a new DAG needs to be generated, the issue is likely the same when we start the miner with overclocking and get tons of invalid shares. That's why HiveOS have a config option to overclock only X seconds after miner start. If I correctly diagnosed the issue, the solution will likely be to either restart the miner on a new epoch or send some message to HiveOS to bring the cards to default settings during epoch changes, or some other software change that makes the cards be in a stable state when loading DAGs while overclocked. I will happily change back to PhoenixMiner when there is a solution for this issue, keep up the great work! Thanks! The most probable reason is too much memory overclock. And if the extreme memory overclock is also applied during the DAG generation, this may lead to corrupted DAG, which then will cause a lot of invalid shares. In 5.5c you can use the option -mcdag 1 to reset the memory overclock during DAG generation. On Windows -mcdag 1 is all you need (provided that you let PhoenixMiner overclock the memory with -mclock +XXXX). However under Linux the things are more complicated because PhoenixMiner can't apply the memory overclock by itself. So, when you specify -mcdag 1 under Linux, PhoenixMiner searches for a shell script named daggen.sh, and if there is such a script, it is called once for each Nvidia GPU, passing the GPU index as the first argument, and PCIE bus ID as second argument. You must put in this script commands to reset the memory overclock, and to schedule re-applying the memory overclock after about 60 seconds (to be sure that the DAGs are already generated). The miner will then wait for about 7 seconds before starting DAG generation to allow the script enough time to reset the memory overclock. Hi! Im new around here and registered here because i need little or big help with phoenixminer. I have used it about 12 months now but recently it keeps crashing. Especially after Devfee. example from log file: 2021.03.14:12:27:51.524: eths Eth: New job #89981f0a from ethash.poolbinance.com:1800; diff: 1073MH
2021.03.14:12:27:51.902: main DevFee: Disconnected and stopped
2021.03.14:12:27:54.975: main GPU1: 47C 77% 96W, GPU2: 49C 74% 98W, GPU3: 41C 75% 98W, GPU4: 46C 78% 93W
GPUs power: 385.0 W; cost: 0.55 USD/day
2021.03.14:12:27:55.376: main Eth speed: 158.749 MH/s, shares: 255/0/0, time: 0:30
2021.03.14:12:27:55.376: main GPUs: 1: 39.546 MH/s (67) 2: 39.759 MH/s (65) 3: 39.722 MH/s (67) 4: 39.723 MH/s (56)
2021.03.14:12:27:56.381: main Restart timeout reached any ideas why? After "restart timeout....." command panel just closes. No warning/error... nothing. Just closes. config file look like this(i using -li 1 because stability no other reason): -pool stratum+tcp://ethash.poolbinance.com:1800
-wal xxxxxxxxx
-amd -timeout 30 -lidag 2 -gt 6 -altinit -wdog 1 -wdtimeout 30 -li 1 -hstats 2 -prate 0.06 -rxboost 1
You just need to remove the -timeout 30 option from your config.txt file as it literally forces the miner to restart after 30 minutes (do not confuse -timeout with -wdtimeout, these are very different options). Here is the help for -timeout: -timeout <n> Restart miner according to -rmode after n minutes Is there any way to delay the application of overclock on the core during dag creation. I know its possible on the memory with -mcdag but Im having issues on the coreclock during dag creation process. I know increasing memory will increase the hashrate but in my case, increasing the coreclock increases the hashrate as well. Weirdly it only happens on my gtx 1070.
Not that weird - the TLB cache is part of the core, and its speed is the limiting factor of the hashrate of GTX1070 with the current DAG sizes. We could add it but not in the next release. Is there any way to fix this TLB cache problem? I am one of probably many 1070, and 1080Ti users that would be grateful if there would be some kind of fix for this problem in the upcoming releases. We are losing 4-10 mh/s per card now as oppose to 2017. Tnx. We tried a lot of different approaches in the past but none of them worked. Only Nvidia knows if these GPUs (most of the Pascal series expect 1070Ti) even have the hardware ability to increase the virtual page size (the only thing that would fix the problem properly) like AMD did with the Polaris cards a few years ago. The whole point is moot now because even if Polaris GPUs are capable of larger page sizes, Nvidia wouldn't be bothered to release fixed drivers anyway. Could some one pls tell me what command must be entered in the bat file that replaces the pill for ether?
With the pill I have around 10 mh/s increase on my 1080ti, but somewhere was mentioned now there's a command that renders the pill useless.
Im currently getting around 47,7 mh/s on a palit 1080ti Jetstream 85 tdp, 220 core, 330 mem. At very few occasions it jumps to 49 mh/s when I put EXACTLY 200 core/ 230 mem, but if goes back down to 47 whe new dag file loads or smt.
Lowering tdp below 75% or core clocks drives the speed down significantly. Any idea on different settings that can push it to 49?
Thanks!
You don't need the pill with PhoenixMiner. You need to add the option -straps <n>. Start with -straps 1, and the try the higher values to see how much tighter timings the card can take. You can also try fine-tuning the memory timings with the command-line options -vmt1, -vmt2, -vmt3, -vmr - check the documentation for more information about all these options. Tnx. I will check the data and the logfiles.
When I run the miner in the console as far as I know it always starts with the card names.. (which GPU are found for mining) In this list it shows 6 times the same (type) cards RX 580
I even had fitted the RX 5700 as a single available GPU, but then I get the miner error "NO GPU for mining"
Is there any known hardware limit for getting the RX 5700 XT's to work in Phoenixminer, e.g. minimum of RAM used, or anything else, which we might have overlooked?
The rig is fitted with only 4 Gb RAM. (We use the Asrock H110 BTC Pro+ mobo)
Perhaps the driver version may be the issue. Do not use the latest AMD Linux drivers for anything other than RX6000 AMD cards. |
|
|
|
@PhoenixMiner
Any plans for monitoring and allowing fan control based on memory temperature?
Aside from the weirdness going on lately, Nicehash Quickminer does have some really nice new features. Itcan set fan speed based on monitoring of 'Hot Spot' memory temp in DDR6 cards and Memory TJ on 3080/90 cards.
Yes, there will be several options to control the junction temperatures and memory temperatures with the fan speed in the new version but only for AMD cards that report these temperatures. We are working on the same feature for Nvidia 3080/3090 but we are not sure it will make it for the next release. Is it me or has Mega always been a bit sketch?
Everyone used it for hosting mining software when we started, and we usually don't try to fix things that aren't broken. Of course, after terminating our account, we had no choice but move elsewhere. It is encouraging that other miner software survives fine on github, so hopefully it will be our new hosting solution. Is there any way to delay the application of overclock on the core during dag creation. I know its possible on the memory with -mcdag but Im having issues on the coreclock during dag creation process. I know increasing memory will increase the hashrate but in my case, increasing the coreclock increases the hashrate as well. Weirdly it only happens on my gtx 1070.
Not that weird - the TLB cache is part of the core, and its speed is the limiting factor of the hashrate of GTX1070 with the current DAG sizes. We could add it but not in the next release. Hello all,
Want to mention first that I am not here to blame anyone, probably the only one to blame is just me for not enabling 2FA.
I got hacked and here is the story.
Been using NH for about two weeks, I was like, let me jump on the train with the rest.
....
It's hard to tell - could be anything. We know that the (non-fake) releases of PhoenixMiner are clean but we can't speculate for the rest. It could even be some kind of vulnerability at a browser, or OS level. We would recommend using firewall that is blocking outgoing connections (in the default state Windows firewall only asks for permission for incoming connections and allows all outgoing connections). With such firewall even if something is compromised, at least it won't be able to "phone home". These firewalls are a bit of pain in the ass to configure though, as a lot of things connect to the Internet all the time. Situation:
We are no experts miners..
First we used 6 Radeon RX 580 GPU's (mixed brands) with Ubuntu as OS and Phoenixminer 5.5c as miner for a while.. Then we added a 7th 580 which came available and with no hussle we got it running. I have been busy to get the best settings for each card and got decent hashrates..
Now we wanted to up the hashrates by replacing the 580's GPU's with RX 5700 XT's one by one.
But for some reason we do not get the first one to be recognized in Phoenixminer.
It shows in the PCI list of Linux..
To make sure the 580's would run kind of optimized and since I do not know yet at what GPU number the 5700 would be get by phoenixminer, I wrote following lines in the config file:
-cclock RX*580:1150
-cvddc RX*580:850
-mclock RX*850:2175
-mvddc RX*580:860
As I understood from the help for the config file this should set the core/mem clock and voltage for all GPU's that are named RX AND 580 with the specified numbers.. all other cards (the RX 5700 XT) should use their default.
But when the miner is started the settings are not used and the RX 5700 is not displayed and we start mining with only 6 iso 7 cards.
I tried to look for any sollutions already but came without any..
Any help, ideas are highly appreciated.
The commands look fine but you need to check how the cards are listed by the miner when you run ./PhoenixMiner -list. Some cards may be named differently and won't match the selector in the commands. You should also check the log for applying the clocks and voltages for all cards. For example: 2021.03.14:04:14:44.503: hwmc GPU1: set GPU clocks to 1090 MHz (Vddc 920 mV)
2021.03.14:04:14:44.510: hwmc GPU1: set VMEM clocks to 2000 MHz (Vddc 900 mV) |
|
|
|
I hope this post does not get deleted, because my posts were getting deleted.
Not by us, we can't delete any posts here, and if your posts got deleted on bitcointalk.org, you are probably in the wrong. Also, complaining about deleted posts is a bit rich, after your company locked up the thread started by us on your subreddit. I am making this post on my behalf, has nothing to do with NiceHash and NiceHash is not aware of it. This is my personal view and NOT a statement from NiceHash.
So what exactly is your position in NiceHash? Owner, CEO, just another employee? Did you had any part in taking these decisions? You can't have it both ways - talking like you own (or at least run) NiceHash, then go back to just sharing your "personal view". Let's start with timeline several months ago, before the big BTC hype, when BTC was still just around 10k. Who was mining back then? Old school miners...
Fortunately (at least from our perspective), the vast majority of miners are still old school. Yes, NiceHash do have 3rd party EULA that every user has to confirm, but like I mentioned before, nobody was reading that. People gave jack shit about it and really didn't care. They were under complete illusion that "NiceHash is a big company, they surely must have taken care of what I am installing, no?". Perhaps if this happened and there was a court case, NiceHash could win, but that doesn't mean NiceHash would survive.
Let's just stop with all this nonsense about "corporate responsibility". The most important reason to create a corporation, is to limit the responsibility of the owner(s)! But even if we accept that you were genuinely concerned for your users, where is the huge post on your site, warning users about the latest Windows vulnerability for example? Where is the post saying "format your disks, install the latest revision of Windows 10 immediately by downloading it directly from Microsoft, and change all your passwords because of XYZ"? And when we took a deeper look - developer gone for 1.5 months, constant attempts to push 5.5d bins, someone was doing hash checks and said these don't match (not sure why that was but as later found out - probably because of different zip files), it was just a big panic and a race with a time - if there is a malicious attempt, we need to inform users ASAP and reduce possible damage.
Posts with fake versions of PhoenixMiner have appeared on this thread for years! All of them were promptly removed by the moderators. What changed on March 6th (besides MEGA deleting our account)? And the story about the checksums is pure BS. Of course the checksums of the fake 5.5d won't match with these that are posted by us here - that is the whole point of the checksums! Considering how long developer did not react (it must have been like 3 days), we were sure he/she/they are not coming back and the only question remaining was: is there an exit scam or not?
Yes, we are guilty of not reacting in time. The only thing that we can say in our defense, is that none of us really subscribes to, or participates in the modern way of living our lives "online" all the time. We check our devfee hashrate for any indication of anything wrong happening multiple times a day but otherwise, we keep our work and our lives mostly offline except around the releases of the PhoenixMiner. Perhaps we were too complacent, and we have taken steps to make sure we react much faster should anything like this happens in the future. But on Monday morning, look, developer is back! I was sure, we need to make an apology now. Even though, we never said that there is malware, we only warned users there COULD be, people panicked and simply overlooked our "COULD" word. So, my belief was to make a sorry statement at least for this indirect damage. And if you ask me, I am still sorry for this. I know what it means, if developer intentions are not harmful, and until there is name to be kept, I am sure, intentions are not harmful. I know how much damage from reduced income this must have caused. But I cannot decide for the company what statements to give out. This is not in my power and voting was against doing this. If it helps you PhoenixMiner, personally, I am sorry for this, truly I am.
A five-year-old would come up with a better apology. "I'm sorry, but it wasn't my fault anyway." Now, let's also debate the other very suspicious events that were going on before developer reappeared and which do not make much sense and were completely unnecessary and must have been related to something else, which made the whole disappearance even more suspicious. I believe, if there were none of these activities, things would probably go into different direction, perhaps even towards official sorry statement.
So, after the announcement was made, there was immediate FUD by Josip Juhas, that NiceHash has pushed malicious 5.5d binaries to all NiceHash users and that this is just a campaign to fix own mistake. I have asked Josip to take this statement down, because it was not true. It was not true according to the source code, which is publicly available and everyone can analyze and confirm that this could not have happened unless the real developer pushed these bins on Mega.nz. Also, not a single user reported getting 5.5d bins and nobody reported anything about being infected. But Josip Juhas continued pushing this FUD to the point so others have copied his statement, including Alchemy from RedPandaMining and this statement was then spread by RedPandaMining all around the community through his YouTube channel. Besides that, someone (definitely not developer) also started massive shill campaign on all social media posting either this exact same FUD about 5.5d binaries being pushed or diversion - some events from NiceHash's history to discredit NiceHash warning as false and as something you really don't have to worry about. I cannot prove who was behind this campaign, but if developer wasn't available, then I would guess it was definitely NOT the developer. And the developer would be the only one having interest doing that. So who else would be doing that? I still don't know, but if I'd have to point my finger I'd say Josip Juhas. It fits his profile. Why?
OK, let unpack this. You obviously have a beef with this person, and you may very well have good reasons for this. So, let's set the record straight: we don't have any business with him, the only association is that we added link to minerstat in our main post after he asked us nicely in a PM - the same as with the other few links in our first post. None of them paid us with fiat, crypto, or in any other way, all they did was to tell us "Hey, we are featuring your miner on our site/service/whatever since forever, would you add a small link to us?". After a quick check of the website or service in question, we did add a link. We can't do detailed background check or ask them for they real identities, nor do we want to. We never received any complains about these services being untrustworthy, or malicious. With that being said, why can't you admit that you have created this shitstorm yourself? The hysterical blog post of your site was indicative of something much more serious than " the developer of PhoenixMiner disappeared, and his MEGA account was deleted". Given your past security record, a lot of people probably thought that there must be something that you are not telling them, like mistakenly pushing the fake version of PhoenixMiner on their PCs, and then trying to absolve yourself of any responsibility. So, you have to either admit your employees are grossly incompetent, or that you had created this FUD campaign for other reasons. We don't think your employees are that incompetent. Let me tell you something about Josip Juhas, aka minerstat owner. Josip Juhas was convicted two times in Slovenia and spend some time in prison.
...
How do I know this? Josip Juhas once worked for NiceHash. He resigned somewhere in the middle of 2017. He wasn't fired, he resigned, let me make this very clear.
Let us get this straight. You knew about his criminal past, yet you hired him? Well, this sure seems to be a recurring theme in NiceHash! In contrast, none of the people on our team were ever convicted, or even accused of any criminal activity. It's probably part of the reason why we can't find common ground - your environment and values are quite different than ours. So, be very careful when you deal with him. Never make any business with him. Better not even talk to him.
...
And regarding Josip Juhas. Well, we can just hope that he doesn't murder us all... because after all... he could be capable doing that.
Don't worry, we are not making any business with him (in case your concern is genuine). However the same goes for you. Your attempts to make us reveal our real identities were quite chilling. After all this, can you blame us that we don't want to reveal our identities? We don't have a problem with our respective governments knowing our identities, as we pay all required taxes, but we won't risk our well-being just so that you can have piece of mind by knowing who we are. So, what will happen now in the future? NiceHash Miner will introduce some way of putting PhoenixMiner back in, it just isn't going to be automatic download by NiceHash. That is just way too risky. When people manually insert miners in, then NiceHash cannot be responsible for anything malicious if it ever happened. Similar destiny awaits all other anonymous miners. We don't hate PhoenixMiner and we did not want to destroy PhoenixMiner. This is just malicious talk. There was a risky situation and we had to take extraordinary action to protect NiceHash.
Nothing changes for us too. We will warn people to be cautious when doing business with NiceHash. There are just too much shady things connected to your company - people with past criminal activity, security breaches, theft of huge amount of BTC, not taking any responsibility for preventing 51% attacks on the weaker coins through your service (how hard could it be to detect the mined coin by the DAG epoch, and to sound the alarm if someone tries to mine XYZ with more than 51% of the current network hash?). Finally, let's just stop with this BS, as it benefits no one. Everyone can make their own conclusions, and we are are sure that most miners have much better things to do with their time than reading about this storm in a teacup. We know we do. |
|
|
|
I'm currently mining with PhoenixMiner using NiceHash (I would stop using NH if I felt I could make batch file correctly!) as it is by far the best miner I've used due to how stable it is, the level of info displayed and the amount command line of switches.
I'm only using my laptop (yes well aware of the risks and I know I'm not going to make a fortune) with its GTX 1660 Ti (temps around 65-67 with good airflow) and I use the following extra launch parameters:
-lidag 3 -mcdag 1 -mi 14 -nvdo 1 -eres 3 -cclock -305 -mclock +575
My questions are am I using them correctly? Are there some where the value could be changed? Do I need all of the ones I'm currently using?
Thanks in advance!
The parameters are fine but you may try using -powlim to lower the core clock instead of using -cclock. On most Nvidia cards -cclock will not lower the voltages sufficiently (or at all), and the GPU will consume more power than needed. Start with -powlim -10 (this will decrease the power limit by 10%), then try decreasing the power limit further (e.g. -powlim -20) until the hashrate starts to be affected. I don't blame you for wanting to keep your identity a secret, and good job standing your ground. I wouldn't have reacted to Nicehash's message any differently. However, there were a few days this past week where your clients were scrambling trying to find your software, and since this thread is under constant attack by malware shilling sockpuppets, this episode put your clients in a high-risk situation. Many didn't know whether the software they found was the right version, and there was also suspicion that your Mega and Bitcointalk.org accounts were hacked, or (god forbid,) you went rogue yourself. Checksums are great, but they don't guarantee that your accounts haven't been hacked, or the software and checksums weren't replaced by the hacker. To help the members of this forum (and the folks at Github will appreciate it also) I suggest you create and stake a PGP key that you use to sign the binaries and/or the checksums. That gives the community a second factor for authentication. If this kind of thing happens in the future we can use the PGP to authenticate your checksums or the binaries and avoid this kind of drama. This is not a bad idea, and we will definitely look into it. Our main concern is with github - if somebody starts complaining to them like they did to MEGA, they may close our account there too. We already prepared a few backup hosts but won't make them public until they are needed (hopefully not soon). Well for me I am and have been using most versions of Phoenix miner with no issues. I am currently using Phoenix 5.5c within the Nicehash miner for about the last month. Only to switch things up for a BTC payout. Otherwise I normally have used the Phoenix miner as a stand alone. I am glad to see the Phoenix devs coming forward to defend themselves and go to lengths to give reassurance on their software and that they are not "MIA" Lets hope both Nicehash and Phoenix can find a middle ground and get this resolved soon for the benefit of everyone who uses both software's. Its not healthy for the mining world to have doubts on either side. MMNC We certainly don't want any "wars" with NH, or anybody else. If they were just telling their clients to avoid third-party miners (and they are doing this for months) without spreading any FUD, well, we may not like it but we would accept it without any complains. But apparently that wasn't enough to move people to their miner, so they had to start smearing us. Hi, hoping for some help with 1 of my 3090's I use for mining. Using v5.5c.
The problem I'm having is as soon as it hits around 60c temp, the performance drastically goes down. For some reason the card stops pulling the usual ~350 watts and only draws ~270 watts after 60c ish temperature is hit. I have a 2nd 3090 which pulls much higher, has no monitors plugged into it and draws around 400 watts. That card will happily go up to 66-67c temps and remains at the 400 watts draw. I'm really scratching my head with the first 3090. It hurts watching it's hshrate go from 120mh to 90mh just because the temp climbs from 56c to 60c lol. Meanwhile the 2nd card doesn't seem to care about temperature and will chug away doing 122mh with 400 watts.
If you need any extra information such as logs, OC settings etc then please let me know and I can provide them.
Yes, a log will be helpful, but first make sure you add the command-line option -hstats 2 to see the actual clocks, and the reason for throttling (we assume that there is throttling involved), and because 60C is too low for temperature-related throttling, it is probably power-related but we need the log for more information. If the card is throttling because of the power limit, you can increase it with this option -powlim +20,0 (the 0 is to leave the power limit of the second card at default value as it doesn't have throttling issues). Hi Phoenix, thanks for the response. I've added in the command line options you suggested and ran the miner for a couple minutes. Sadly the -powlim argument didn't really help. I wasn't sure what the most convenient way of sharing the log would be so I just went ahead and threw it in a pastebin. You can see that here: https://pastebin.com/q780sgsLThe exact cards are EVGA 3090 FTW Ultra's and I'm using EVGA's Precision X1 overclocking software. The OC settings I'm running are the same for each card and they are as follows. GPU: -400 Mem: +1200 Power and Temp target slider is maxed at 119% for power and 91c for temp. The fans are also all set to 100%. The log also shows that the performance cap (throttling) reason for the first GPU is the temperature: GPU1: cclock 990 MHz, cvddc 743 mV, mclock 10702 MHz, p-state P2, pcap temp The others called it correctly - the memory is overheating. ... and when we release the actual new version, it will not be named 5.5d[/b].
Hello. Thanks for the releases. Will you add more DAG epohs in the next release? We will but even the current limit (epoch 500) should be enough for at least 14-15 more months. Hello. Thanks for the releases.
Will you add more DAG epohs in the next release?
I agree. Current epoch # 400, there are less than 100 left because I think that it will stop working much earlier than 500. I saw some other ethash miners add more DAGs... No, 5.5c will work without any problems until epoch 500 (provided that you have enough VRAM). But it is not a big deal to increase limit, and we will do so for the next release. You could opt for a middle ground, producing your own private key and signing all subsequent PhoenixMiner releases with it, without registering with an official CA to sign that key. You could then post your public key here in the thread's first post, so any future binaries can be verified against it.
Yes, it seems that a lot of people will be OK with this, so we will probably do it soon. We will also put the public key in another big "verifying" transaction to prove we are behind it. Dear Phoenix Miner Dev,
With the impending end of life for ethereum mining in the near future any plans to add Ravencoin to the mix since other progpow crypto is already on the list?
Yes, but not in the next release - it is already feature-frozen. But definitely in a few months at most. Phoenix still needs our support because today some of my friends asked if they could use this program.
NiceHash blamed the developer for a lot and still hasn't apologized. But they did not forget to post QuickMiner on Twitter today.
At this rate, Phoenix will become an underpopular miner.
Thank for you support. Do not worry too much about that - people will "vote" with their rigs. If their miner is so good, they wouldn't resort to such dirty tactics, and we believe that whole thing will blow over soon enough. |
|
|
|
|
We greatly appreciate the efforts of the moderators in removing these links, and we are fully aware that it didn't start with us, and we are not that significant in the great scheme of things. Please take our sincere apologies about the situation - it wasn't our intention to start any dispute with NiceHash, or anybody else, and we hope this storm in a teacup will die down soon.
If there is anything we can do in order to help filter out the malicious links, please let us know.
|
|
|
|
Hi, hoping for some help with 1 of my 3090's I use for mining. Using v5.5c.
The problem I'm having is as soon as it hits around 60c temp, the performance drastically goes down. For some reason the card stops pulling the usual ~350 watts and only draws ~270 watts after 60c ish temperature is hit. I have a 2nd 3090 which pulls much higher, has no monitors plugged into it and draws around 400 watts. That card will happily go up to 66-67c temps and remains at the 400 watts draw. I'm really scratching my head with the first 3090. It hurts watching it's hshrate go from 120mh to 90mh just because the temp climbs from 56c to 60c lol. Meanwhile the 2nd card doesn't seem to care about temperature and will chug away doing 122mh with 400 watts.
If you need any extra information such as logs, OC settings etc then please let me know and I can provide them.
Yes, a log will be helpful, but first make sure you add the command-line option -hstats 2 to see the actual clocks, and the reason for throttling (we assume that there is throttling involved), and because 60C is too low for temperature-related throttling, it is probably power-related but we need the log for more information. If the card is throttling because of the power limit, you can increase it with this option -powlim +20,0 (the 0 is to leave the power limit of the second card at default value as it doesn't have throttling issues). |
|
|
|
|
Show Posts
