This memclock is INSANE. Can you post GPU-Z sensors tab please. I have manage to reach around 64mh/s with mem @ 8400, gpu @900 on a legion 5 pro with a RTX 3070 using afterburner curve with voltage at 700. I didn't know you can reach lower voltage with nvinspector! This is the advantage of mobile gpu: their voltage curve can reach lower voltage than their desktop parts (in exchange you loose access to high core gpu frequency / high gpu voltage: which are no use for ethereum mining). Thanks you rednoW for the nvinpector hint!
|
|
|
so far so good T-Rex ok ))
Impressive! Whats settings (memory, core, ...) ? Edit: nevermind, you have posted them in the previous page. Impressive overclock on the memory for a laptop!
|
|
|
To be on the safe side, I would say yes: change your passwords and reinstall your system. Did the program require admin privilege ?
|
|
|
This is bad right ?
Nope, you can use bisq, poloniex or any other exchange Not scared other exchanges will follow? US exchange will probably feel the pressure: this is a possibility. XMR may tank for a while before people realise this is what BTC was supposed to be: a truly censorship resistant and somewhat decentralized coin which preserves freedom for good or not so good use, but freedom after all. I think price at BTC level before it picked institutional interest is a reasonable long term objective : 500-2000 USD or 0.01-0.05 BTC.
|
|
|
This is bad right ?
Well, would they have just delisted XMR, it would have been bullish: since the volume is rather high, the reason is the anonymous feature which may trigger some regulatory concern. It would underlines the rather good anonymous features of XMR. But I am disapointed they also delisted other not so good anonymous coins...
|
|
|
RTX 3090 FE: I had the card for a few weeks: throttle easily in ETH mining, no matter the setting, excepting heavy undervolt/underclock for the core and no overclock for the memory: 105Mh/s-110Mh/s @250-260W is doable. Works OK for Conflux, with carefull settings. RTX 3080 TUF: No problem with ETH mining with core undervolt and memory overclock: core at 1150-1200@0.725mv and mem @ +1200 (10451) gives around 100Mh/s @ 210-215W. But, it needs appropriate case cooling (when I had both card in my case, the TUF was throttling from time to time). Overall, RTX 3090 is not appropriate for ETH mining (even without taking into consideration the price): the doubled memory chip on both side are difficult to cool and leads to an increased power usage. 3080 TUF has appropriate cooling on the mem chip and is OK for ETH mining.
|
|
|
i dont understand 1 thing. mining is all about compute power right? 6900 has twice more compute power than 5700 then.it suppose to be at least 100mhs. i dont understand it.
Minins ETH is very dependant to memory bandwith and memory latency... The 6800/6900 have a bandwith just around 10% more than 5700. The remaining question if the impact of the infinity cache: due to its small size relatively to the DAG size of ETH, it should have a minimal impact on ETH mining. ok then why radeon 7 has : 1,024 GB/s bandwith performing worse than 3080 which has less memory bandwith: 760.3 GB/s . Both bandwith and core are used for ETH: for radeon VII, it is probably limited by core computation, for RX 6900 xt, it is mostly limited by bandwith. For RTX 3080: you should downclock the core at around 1200-1300 mhz (to decrease power consumption almost without losing hashrate) and overclock memory at +1000mhz (around equivalent 10000mhz or more) to have the highest hashrate. Therefore you can conclude that this card is more bandwith limited for ETH mining than compute limited. RX 5700 is well balanced for ETH mining between compute power and memory bandwith.
|
|
|
i dont understand 1 thing. mining is all about compute power right? 6900 has twice more compute power than 5700 then.it suppose to be at least 100mhs. i dont understand it.
Minins ETH is very dependant to memory bandwith and memory latency... The 6800/6900 have a bandwith just around 10% more than 5700. The remaining question if the impact of the infinity cache: due to its small size relatively to the DAG size of ETH, it should have a minimal impact on ETH mining.
|
|
|
My Results with my RX 6800 but not really optimized yet from my side: Ethereum ~62MH/s Kawpow ~32MH/s BeamHashIII ~36MH/s ZHash ~90H/s BFC ~160H/s Only 4 miner (Nanominer, lolminer, PhoenixMiner and at some algorithm GMiner too) support the new RX6000 cards at the moment but I guess, not really optimized to this new GPU - architecture. We will see! Hello, Could you try conflux (CFX) with nanominer please ?
|
|
|
I just saw this on wccftech, and I'm confused to be honest I believe that AMD GPUs will be better for mining, but if we do the math, 120Mhs of 3090 RTX, are doing 3.43 USD daily, according to Nicehash Calculator To gain 1.5 times more, the hashrate of ETH should be 180Mhs It's insane, and if this is true, Infinity Cache is something big for miners I don't know what to think right now, this is not good news, because nobody will have opportunity to buy cards this year If this is talking about ETH then it looks like they just applied AMD's claimed "Infinity Cache" memory bandwidth boost of around ~2x over a 384 bit bus: 384 bit bus bandwidth for GDDR6 at 16 gbps = 384 * 16 / 8 = 768 GB/s With AMD claimed bandwidth boost of ~2x = 768 * 2 = 1536 GB/s Which gives a theoretical zero latency ETH hashrate = 1539 / 8192 * 1000 = 187.5 MH/s 3090 gives about 120+ MH/s So 187.5 MH/s is about 56% more than the 3090's 120 MH/s Looks like they just applied some math to get those numbers. Guess we'll know soon enough how the infinity cache actually affects ETH mining in reality vs. theoretically. taking into account that ETH DAG is too big for the cache, I don't believe this rumoured performance (except if this for another algo than ETH). Beside I am not sure that the whole 128 MB space will be available for caching portion of the DAG...
|
|
|
Eth mining use random access to a 4G DAG file: the 128MB cache should not be helpfull for ethereum. On the other side, it may help for others algo, such as randomx, provided miners are optimized for the new architecture.
|
|
|
Thank you very much for all the work you have done with cpuminer. Funny, I was thinking you were a young programmer motivated by improving his cpu architecture understanding and close to machine coding skills. Well your example shows me I am not too old to improve my coding skill and may motivate me to do this.
|
|
|
I haven't found a xmrig discussion thread so I'll post here. Has anyone gotten cuda-plugin to compile on Ubuntu 18.04? It compiles on 19.04 but 18.04 fails: -- Found CUDA: /usr (found suitable version "9.1", minimum required is "8.0") -- Configuring done -- Generating done -- Build files have been written to: /home/coin/miners/xmrig/xmrig-cuda-2.0.0-beta/build coin@sys24:~/miners/xmrig/xmrig-cuda-2.0.0-beta/build$ make [ 8%] Building NVCC (Device) object CMakeFiles/xmrig-cu.dir/src/RandomX/wownero/xmrig-cu_generated_randomx_wownero.cu.o In file included from /usr/include/host_config.h:50:0, from /usr/include/cuda_runtime.h:78, from <command-line>:0: /usr/include/crt/host_config.h:121:2: error: #error -- unsupported GNU version! gcc versions later than 6 are not supported! #error -- unsupported GNU version! gcc versions later than 6 are not supported! ^~~~~ cc1plus: warning: unrecognized command line option ‘-Wno-class-memaccess’ CMake Error at xmrig-cu_generated_randomx_wownero.cu.o.Release.cmake:219 (message): Error generating /home/coin/miners/xmrig/xmrig-cuda-2.0.0-beta/build/CMakeFiles/xmrig-cu.dir/src/RandomX/wownero/./xmrig-cu_generated_randomx_wownero.cu.o
CMakeFiles/xmrig-cu.dir/build.make:105: recipe for target 'CMakeFiles/xmrig-cu.dir/src/RandomX/wownero/xmrig-cu_generated_randomx_wownero.cu.o' failed make[2]: *** [CMakeFiles/xmrig-cu.dir/src/RandomX/wownero/xmrig-cu_generated_randomx_wownero.cu.o] Error 1 CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/xmrig-cu.dir/all' failed make[1]: *** [CMakeFiles/xmrig-cu.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2
I just asked them about this on reddit, this is their response: CUDA has very strict compiler requirements, so you have 2 options: 1. Update CUDA to recent version. 2. Install older compiler like sudo apt install gcc-6 g++-6 and specify compiler on cmake phase cmake .. -DCMAKE_C_COMPILER=gcc-6 -DCMAKE_CXX_COMPILER=g++-6Link to answer: https://www.reddit.com/r/MoneroMining/comments/dvv637/xmrig_500_stable_release_unified_3_in_1_miner/f7iota4?utm_source=share&utm_medium=web2xinstall latest cuda: it should use gcc 7
|
|
|
why doesn't c29 work with 8gb win10?
Because windows 10 doesn't allow use entire video memory, miner require about 7GB of memory, however windows 10 doesn't allow to allocate 7GB. I suggest use linux, under linux you will even never think about page file size, it always work on standard system settings with any number of devices. why is win10 so stupid https://uk.mathworks.com/matlabcentral/answers/413584-matlab-is-able-to-utilize-only-a-part-of-actual-available-vramThe problem is between wddm 2 (the video driver model of win 10) and nvidia driver. On my amd vega (8G), I have no problem running the miner with 7G allocation on win 10, whereas with the nvidia 8G, this doesn't work. Nvidia has tcc driver which put the card in compute mode (pure mode without wddm) but it is restricted to pro card or titans., not for geforce.
|
|
|
Very confusing... So i installed the new wallet ( 1.0.4028 ), used the paswords to get it working again. One thing is, the old adress i placed as NEVER now expires tomorrow. So i made a new adress again with expire NEVER. So, are the coins i had (have ) send before safe on that adress, or are the going to vanish tomorrow. Or should i send then to the new NEVER adres in my wallet. You have downloaded the beta version: I suggest to use the non beta ones. As said in the medium article, the version number doesn't change with the fix, you may better use the Beam-Wallet-1.0.3976.exe one. I have no problem with this one : the addresses still show "never" for expiration dates.
|
|
|
I have problem. When node is starting following the instruction I got mesage-miner key import failed.What is problem?Maybe with sertificate?
I had similar problem : the miner key generated by the windows wallet seems too long with unusual caracters ... I have started to mine with the pool above.
|
|
|
On pascal (randomhash): hashrate decrease on windows on a 7960x (16 cores, 32 threads) with all 32 threads: from above 3500h/s to lower than 3000. To avoid this problem, I need to limit to 24-26 threads, with around 3200h/s.
With rhmininer with 32 threads, I am at around 3100 h/s. So far, your miner is better: 3200h/s with 24 threads, 175w, instead of 3100 at 200w with rhminer.
But maybe you can manage to solve the problem of hashrate decrease at 32 threads, with a stable 3500 h/s.
We are working on it, however, until a new version appears you should try to install windows 10 linux subsystem and run linux version of FinMiner. I promise you, results will be better. Ok, thanks, I have already installed WSL. I will try tonight. Does performance on WSL similar than a proper linux installation ? Are you sure the higher hashrate is real and not a bug: In rhminer from polyminer, in release notes of 0.9.4: Fixed wrong hashrate on linux. (a thread-concurrency bug made H/S show-up higher on linux.)PS: I have 4450k/s on linux with 24 threads (somewhat optimal setting, more threads gives better hahsrate at the beginning but decreases with time), against 3200kh/s on windows.
|
|
|
On pascal (randomhash): hashrate decrease on windows on a 7960x (16 cores, 32 threads) with all 32 threads: from above 3500h/s to lower than 3000. To avoid this problem, I need to limit to 24-26 threads, with around 3200h/s.
With rhmininer with 32 threads, I am at around 3100 h/s. So far, your miner is better: 3200h/s with 24 threads, 175w, instead of 3100 at 200w with rhminer.
But maybe you can manage to solve the problem of hashrate decrease at 32 threads, with a stable 3500 h/s.
We are working on it, however, until a new version appears you should try to install windows 10 linux subsystem and run linux version of FinMiner. I promise you, results will be better. Ok, thanks, I have already installed WSL. I will try tonight. Does performance on WSL similar than a proper linux installation ?
|
|
|
On pascal (randomhash): hashrate decrease on windows on a 7960x (16 cores, 32 threads) with all 32 threads: from above 3500h/s to lower than 3000. To avoid this problem, I need to limit to 24-26 threads, with around 3200h/s.
With rhmininer with 32 threads, I am at around 3100 h/s. So far, your miner is better: 3200h/s with 24 threads, 175w, instead of 3100 at 200w with rhminer.
But maybe you can manage to solve the problem of hashrate decrease at 32 threads, with a stable 3500 h/s.
|
|
|
As of October 18th, mining pool told monero miners that they had to change miners--we use xmr-stak. We changed ours. We run 7 VEGA 56 cards. We only get 9.2 to 9,3 on the graphs. This is 920 H/S I believe. We used to be able to pull 1200 to 1300 hundred easily. Given that the difficulty is only 49XXXX, should not we be getting higher? Any tips to re-optimize after the form would be appreciated.
Blockchain driver is no longer the best and you may improve hashrate with some tweak to the parameters with the changes of pow. I am using driver 18.5.1 with : { "index" : 0, "intensity" : 1932, "worksize" : 16, "affine_to_cpu" : false, "strided_index" : 2, "mem_chunk" : 2, "unroll" : 8, "comp_mode" : true }, { "index" : 0, "intensity" : 1932, "worksize" : 16, "affine_to_cpu" : false, "strided_index" : 2, "mem_chunk" : 2, "unroll" : 8, "comp_mode" : true }, It gives 1920h/s for a vega 64.
|
|
|
|