Search content
Sort by
Showing 20 of 324 results by Pennywis3
Re: PhoenixMiner 5.6d: fastest Ethereum/Ethash miner with lowest devfee (Win/Linux)
The new beta version is finally ready. You can download PhoenixMiner 5.7a from here:
PhoenixMiner_5.7a_Windows.zip (GitHub)
PhoenixMiner_5.7a_Linux.tar.gz (GitHub)
The new features in this release are:
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.7 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.7a.
PhoenixMiner_5.7a_Windows.zip (GitHub)
PhoenixMiner_5.7a_Linux.tar.gz (GitHub)
The new features in this release are:
- Added lock core clock
- 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.7 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.7a.
Re: Claymore's Dual Ethereum AMD+NVIDIA GPU Miner v12.0 (Windows/Linux)
I will release new version in a few days, the main update is applying memory straps/registers without flashing cards.
Like this:
https://bitcointalk.org/index.php?topic=5123724.0
but for Windows and with more features.
Like this:
https://bitcointalk.org/index.php?topic=5123724.0
but for Windows and with more features.
Is this gonna get applied to the Cryptonote miner too?
Various CN coins have nice profits and there seems to be enough miners behing them, i hope ur thinking in this direction
Re: AMD Memory Tweak - Read and modify memory timings on the fly - [Vega Friendly]
probably gonna install an on the fly in his newest quadra milking (closed source) miner.... at least someone is rich after these massacres.
You are forgeting the thousands of people that got rich beside him on account of his miners.
I'd bet you'd do the same if you had the knowledge
Re: AMD Memory Tweak - Read and modify memory timings on the fly - [Vega Friendly]
Yeah, i figured Claymore would sonner or later go private.
A man with knowledge like that can be a very valuable asset, same as some other individuals in this post
I can imagine how much time and effort someone has to put in to get to the belly of the beast like Claymore has.
The community has gained a lot from him, and hes sure not to blame for his decisions, especially in a dirty bussines like this ( code stealing etc. ).
A man with knowledge like that can be a very valuable asset, same as some other individuals in this post
I can imagine how much time and effort someone has to put in to get to the belly of the beast like Claymore has.
The community has gained a lot from him, and hes sure not to blame for his decisions, especially in a dirty bussines like this ( code stealing etc. ).
Re: SRBMiner Cryptonight AMD GPU Miner V1.8.2 - native algo switching
Doc, do we know why TR has such different power consumption compared to other miners?
Are you working on this? Well, I hope something similar can be implemented in your miner too
Are you working on this? Well, I hope something similar can be implemented in your miner too
Re: [JCE]Fast & stable CN-Heavy/Tube/XHV miner, low power, Vega56 1800+, RX580 1200+
Sorry, but 950mv is not doing 80-83w. I'm assuming you're looking at HWinfo or GPU-z which are not complete, and/or you're forgetting to add in your idle (15w) which still would be too low.
Including idle, at the wall, i see 105-110 @ 850-860mv (1200-1265h/r depending on mem type)
Including idle, at the wall, i see 105-110 @ 850-860mv (1200-1265h/r depending on mem type)
Yeah, you should add about 20-25% to the numbers you're getting in HWinfo.
There's also the PSU quality to consider, you should strive to get as close to 50% PSU as you can where the efficiency is at max.
There can be quite a difference if you're using Gold or a Titanium PSU.
Re: If BTC doesn't close this week above $3000 gpu mining is done
You should mine now more than even, when it rebounds your gonna make some serious cash.
And yes, it always rebounds, there's too much money, development and hardware behind this to fail.
And yes, it always rebounds, there's too much money, development and hardware behind this to fail.
Re: [JCE] Fast & stable CN-Heavy/Tube/XHV miner, low power, Vega56 1750+h/s
Re: SRBMiner Cryptonight AMD GPU Miner V1.7.2 - native algo switching
since version 1.6.0 support GCN card
worse performance drops
purely formal support, for show
there is no practical use
very sorry
your miner was very good before
worse performance drops
purely formal support, for show
there is no practical use
very sorry
your miner was very good before
The performance is getting better, there are no drops.
Don't blame the miner, you're doing something wrong.
Re: [JCE] Ultrafast CN-Heavy/Tube/HVX miner, low power, Vega56 1750+h/s
Hey JCE
I figured out a manual fix to get those rx 580 cards to hash at max speeds on Heavy and be stable, any time i see one that has lost the max speed, i pause/unpause 4 times each (8 button pushes) in quick succession and the card comes back to maximum speed. May be something like this can be coded into the miner?
I figured out a manual fix to get those rx 580 cards to hash at max speeds on Heavy and be stable, any time i see one that has lost the max speed, i pause/unpause 4 times each (8 button pushes) in quick succession and the card comes back to maximum speed. May be something like this can be coded into the miner?
Yeah, I've been doing this since 0.33B5 and it works on all my rigs, except sometimes it takes more than 4x pause/un-pause. This also works on SRB miner, but takes a bit more time to achieve.
In the end you get all the card hashing at max speed this way.
Re: SRBMiner Cryptonight AMD GPU Miner V1.7.0 - native algo switching
RX 570/580 8GB's are pulling 1.1k+ on heavy easy, on low clocks 1.200Mhz or below.
You're doing something wrong dude, unless you're running 1.100Mhz clocks at very low voltages.
You're doing something wrong dude, unless you're running 1.100Mhz clocks at very low voltages.
Testing JCE 33b5 on RX580 8GB cards (x8) with heavy using win 10 x64 with Adrenalin 18.6.1.
Similar findings as above, big issue with warm-up, only a few cards will hash at full speed, others just don't want to wake up
The speed seems better by about 5-10%, although the miner behaves the same as if you would set too much intensity, when you only get a few cards hashing at full speed.
Similar findings as above, big issue with warm-up, only a few cards will hash at full speed, others just don't want to wake up
The speed seems better by about 5-10%, although the miner behaves the same as if you would set too much intensity, when you only get a few cards hashing at full speed.
Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature 
I hope i'll be able to release the v8-capable CPU version soon.
I hope i'll be able to release the v8-capable CPU version soon.
Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.
Just sayin', so you don't get left behind
While i do agree with you and think that auto algo switch is a good idea and can create better profits, i also think that the way is currently implemented in other miners is very trivial and thus i refused to use it. The fact that you need to manually configure and test every algo is wasting time in my opinion. Another waste of time is that in the current trivial implementation, the miner has to restart when changing the algo.
What i really hope is that in the future more altcoins will implement algos that are very compatible with what Monero is putting out there and that due to this, miner software can be modified to perform an auto algo switch as fast as they do the devfee switch.
At this point i find the current implementation of algo switch more of an interruption to mining with very small increase in profits.
XMrig does what you describe, it changes algo without restart or compile and it will also benchmark your rig so you are left just with the fine tuning.
I hope that something similar can be implemented into JCE and others, especially SRBminer that has really awkward and way too long algo changes ( restart + compile + warmup ), which makes it useless for algo switching
Miner developers should really look at MoneroOcean + XMrig, algo switching is done on the fly and really well implemented, and since we have tons of CN based coins one could assume algo switching is gonna become even more popular in the future.
You can check CN mining pool profits below ( especially for last half a year ).
https://moneroocean.stream/profits/
Oh, i never tried this feature, sure it's a lot more useful than the autoswitch when Monero forks (twice a year). I'm still not confident to have time enough to implement it, but you convinced me it's not just a gadget feature
I hope i'll be able to release the v8-capable CPU version soon.
I hope i'll be able to release the v8-capable CPU version soon.
Moneroocean pool also uses XMrig for algo switching, it's really useful and gives nice profits.
XMR Stack can also be compiled to use algo switch, and SRB also supports it.
Just sayin', so you don't get left behind