Default Cuda installed in nvOC is 9.2
I think if you use the pre-compiled version from GitHub, it uses cuda from nvidia 410 driver, which is cuda 10
If recompile it, it should use cuda 9.2 from nvOC
Test both see which one gives better hash rate.
No, i compiled Xmr-stak 2.10.0 like my "how to" described last saturday. I manually compiled it after a git clone in src folder of xmr-stak. |
|
|
|
Different cuda versions shown by nvcc and nvidia-smi:
CUDA has 2 primary APIs, the runtime and the driver API. Both have a corresponding version (e.g. 8.0, 9.0, etc.)
The necessary support for the driver API (e.g. libcuda.so on linux) is installed by the GPU driver installer.
The necessary support for the runtime API (e.g. libcudart.so on linux, and also nvcc) is installed by the CUDA toolkit installer (which may also have a GPU driver installer bundled in it).
In any event, the (installed) driver API version may not always match the (installed) runtime API version, especially if you install a GPU driver independently from installing CUDA (i.e. the CUDA toolkit).
The nvidia-smi tool gets installed by the GPU driver installer, and generally has the GPU driver in view, not anything installed by the CUDA toolkit installer.
Recently (somewhere between 410.48 and 410.73 driver version on linux) the powers-that-be at NVIDIA decided to add reporting of the CUDA Driver API version installed by the driver, in the output from nvidia-smi.
This has no connection to the installed CUDA runtime version.
nvcc, the CUDA compiler-driver tool that is installed with the CUDA toolkit, will always report the CUDA runtime version that it was built to recognize. It doesn't know anything about what driver version is installed, or even if a GPU driver is installed.
Therefore, by design, these two numbers don't necessarily match, as they are reflective of two different things.
So, perhaps we have to indicate the path when we compile the program ? In makefile ? My miner mine, but i don't know which cuda version it's using ...I have find how to determine and do the best compilation of xmr-stak. |
|
|
|
Today I noticed it too, while I have not installed cuda-10 on my rig nvidia-smi shows cuda-10 But my default cuda version is 9.2 m1@m1-desktop:~$ cat /usr/local/cuda/version.txt
CUDA Version 9.2.148
I have the same problem while i don't upgrade yet. Have you tried beta_testing: bash nvOC miners-upgrade
Then let it recompile XMR_Stak?
I recompiled xmr-stak from 2.9.0 to 2.10.0 at 16h30 like my last message looks. I will upgrade later. I'll have to test this foreman interface. For sure. For now, it seems that the fork of monero has not changed anything, it has even made things worse since there is 90% of the hashrate that is dominated by ASICs or AMAPs, against 60-70% before the fork , which makes the network still more vulnerable! AND does not prevent extreme centralization. |
|
|
|
I have a problem from several month with xmr-stak : When xmr-stak start, i can read theses messages : [2019-03-09 16:31:28] : Mining coin: cryptonight_r
[2019-03-09 16:31:28] : NVIDIA: try to load library 'xmrstak_cuda_backend_cuda10_0'
WARNING: NVIDIA cannot load backend library: libxmrstak_cuda_backend_cuda10_0.so: cannot open shared object file: No such file or directory
[2019-03-09 16:31:28] : NVIDIA: try to load library 'xmrstak_cuda_backend_cuda9_2'
WARNING: NVIDIA cannot load backend library: libxmrstak_cuda_backend_cuda9_2.so: cannot open shared object file: No such file or directory
[2019-03-09 16:31:28] : NVIDIA: try to load library 'xmrstak_cuda_backend'
NVIDIA: found 10 potential device's but when i use nvidia-smi command, i can see that i have CUDA 10.0 : nvidia-smi
Sat Mar 9 16:16:40 2019
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 410.66 Driver Version: 410.66 CUDA Version: 10.0 | and when a i compiled the latest xmr-stak version, i saw that several backend had been compiled : [ 70%] Built target xmr-stak-backend
[ 72%] Building NVCC (Device) object CMakeFiles/xmrstak_cuda_backend.dir/xmrstak /backend/nvidia/nvcc_code/xmrstak_cuda_backend_generated_cuda_extra.cu.o
[ 75%] Building NVCC (Device) object CMakeFiles/xmrstak_cuda_backend.dir/xmrstak /backend/nvidia/nvcc_code/xmrstak_cuda_backend_generated_cuda_core.cu.o List of files in my xmr-stak folder : :~/NVOC/mining/miners/XMR_Stak/2.10.0$ ll
total 50104
drwxrwxr-x 2 m1 m1 4096 Mar 9 16:26 ./
drwxrwxr-x 9 m1 m1 4096 Mar 9 16:30 ../
-rw-rw-r-- 1 m1 m1 6729 Mar 9 16:22 config.txt
-rw-r--r-- 1 root root 58488 Mar 9 16:21 libxmr-stak-asm.a
-rw-r--r-- 1 root root 2569042 Mar 9 16:21 libxmr-stak-backend.a
-rw-r--r-- 1 root root 74734 Mar 9 16:21 libxmr-stak-c.a
-rwxr-xr-x 1 root root 44997624 Mar 9 16:21 libxmrstak_cuda_backend.so*
-rwxr-xr-x 1 root root 2014400 Mar 9 16:21 libxmrstak_opencl_backend.so*
-rw-rw-r-- 1 m1 m1 4606 Mar 9 16:24 nvidia.txt
-rw-rw-r-- 1 m1 m1 2482 Mar 9 16:24 pools.txt
-rwxr-xr-x 1 root root 1550280 Mar 9 16:21 xmr-stak* What's the problem on my system that indicate i have not the good CUDA backend ? How can i remedy/resolve this problem ? |
|
|
|
You have to compile yourself this new xrm-stak release and remake these 2 symbolic links path "recommended" and "latest"
commands :
1/ download and compilation
[code]cd /NVOC/mining/miners/XMR_Stak/src (there must not already be a folder named xmr-stak)
git clone https://github.com/fireice-uk/xmr-stak.git
cd xmr-stak/xmrstak/ => Modify the donate-level like you wish to donet at the develeppers that is 2%, save the file, and quit by command cat donate-level.hpp (to verify this changes)
cd ..
mkdir build
cd build/
cmake ..
make install wait for several minutes, the compilation remains stuck or stagnates around 71% to 75%, then progresses rapidly thereafter cd bin/
ll
mkdir /home/m1/NVOC/mining/miners/XMR_Stak/2.9.0/
~/NVOC/mining/miners/XMR_Stak/src/xmr-stak/build/bin$ sudo cp * /home/m1/NVOC/mining/miners/XMR_Stak/2.9.0
cd /home/m1/NVOC/mining/miners/XMR_Stak/
rm recommended
rm latest remake the new symbolic links ln -s /home/m1/NVOC/mining/miners/XMR_Stak/2.9.0 latest
ln -s /home/m1/NVOC/mining/miners/XMR_Stak/2.9.0 recommended Changes made to the various files to allow the use of the new version of xmr-stak (2.9.0) in nvOC 19.3.0 : Changes in 0miner file (adding) : elif [[ $ALGO == CRYPTONIGHTV7 || $ALGO == CRYPTONIGHTHEAVY || $ALGO == CRYPTONIGHTV8 ]]; then to elif [[ $ALGO == CRYPTONIGHTV7 || $ALGO == CRYPTONIGHTHEAVY || $ALGO == CRYPTONIGHTV8 || $ALGO == CRYPTONIGHTR ]]; then and a little bit below if [[ $ALGO == "CRYPTONIGHTV7" ]] then UCCALGO="--currency cryptonight_v7" elif [[ $ALGO == "CRYPTONIGHTV8" ]] then UCCALGO="--currency cryptonight_v8" elif [[ $ALGO == "CRYPTONIGHTHEAVY" ]] then UCCALGO="--currency cryptonight_heavy" fi to if [[ $ALGO == "CRYPTONIGHTV7" ]] then UCCALGO="--currency cryptonight_v7" elif [[ $ALGO == "CRYPTONIGHTV8" ]] then UCCALGO="--currency cryptonight_v8" elif [[ $ALGO == "CRYPTONIGHTHEAVY" ]] then UCCALGO="--currency cryptonight_heavy" elif [[ $ALGO == "CRYPTONIGHTR" ]] then UCCALGO="--currency monero" fi Note 1 : Developpers alert us on their gihub page by this message :Select the currency monero to switch automatically the algorithm from cryptonight_v8 to cryptonight_r So, i choose to define UCCALGO="--currency monero" instead of UCCALGO="--currency cryptonight_r" for the moment In 1bash file in # Algo definitions and Coin->Algo mappings added CRYPTONIGHTR here : ALGOS="BITCORE CRYPTONIGHT CRYPTONIGHTHEAVY CRYPTONIGHTV7 CRYPTONIGHTV8 CRYPTONIGHTR DECRED EQUIHASH ETHASH GRS LBRY LYRA2V2 LYRA2Z MYR_GR NEOSCRYPT PASCAL PHI1612 PHI2 SIA SIB SKEIN SKUNK X13 X16R XEVAN ZHASH" and here : BITCORE_COINS="BTX" CRYPTONIGHT_COINS="KRB,NICE_CRYPTONIGHT" CRYPTONIGHTV7_COINS="ETN,NICE_CNV7" CRYPTONIGHTV8_COINS="MPH_CRYPTONIGHTV8,NICE_CNV8" CRYPTONIGHTR_COINS="XMR"CRYPTONIGHTHEAVY_COINS="LOKI,NICE_CNHEAVY" DECRED_COINS="DCR" EQUIHASH_COINS="ZEC,ZEN,HUSH,ZCL,BTCP,KMD,ZPOOL_EQUIHASH,MPH_EQUIHASH,NICE_EQUIHASH,VOTE,BTCP,BCI" ... ... ... I removed XMR from CRYPTONIGHTV8_COINS line in # Algo->miner mapping and specific settings Section added : ## CRYPTONIGHTR CRYPTONIGHTR_INTENSITY="5" CRYPTONIGHTR_MINER="XMR_Stak" CRYPTONIGHTR_WALLET_FORMAT="$WALLET_ADDRESS_FORMAT"[/code] |
|
|
|
Another news about monero algo fork and my favorite miner xmr-stak : https://github.com/fireice-uk/xmr-stak/releases/tag/2.9.0This release introduce cryptonight_r required for the Monero for on 2019/09/03. Select the currency monero to switch automatically the algorithm from cryptonight_v8 to cryptonight_r with the Monero blockversion 10.
Please note that this version is a bit rough around the edges due to the emergency nature of Monero fork. CPU mining in particular will be very slow. We plan to release a more polished version around the fork date. therefore, can you modify the appropriate scripts so that they can run xmr-stak with the adapted command that will select the new cryptonight_R algorithm? it is currently not available in the 1bash and therefore not in the 0miner file either. NB: I have not yet tried the new version of testing with this new interface that seems to bring something very attractive visually, but I'll see what I can do after the fork of Monero translated from french by google traduction |
|
|
|
xmr-stak 2.8.3 is now compiled on my miner and operate at 5120 H/s in CNV8. slithly more effcient than prévious version. I dont't know if this new version is ready for the next monero hardfok in 9 march. if i read exactly, they wil use a CNV8 algo that they slighly modified to counter the new hybrid ASICs and FPGA miners that appears in décember 2018 and that represent now more than 65% of XMR hashrate. good mining to all of you. |
|
|
|
You are right, lets keep this about Monero. I'm only interested in the ASIC mining aspect / discussion.
Some see ASIC development as a logical next step in a ongoing hardware evolution within crypto (specifically proof of work crypto).
Kinda like The Borg : highly adaptable and futile to resist...
With regards to centralization : i think that will happen at some point anyways, even with networks with only GPU's.
It will just be in the form of centralized GPU hubs, created by wealthy miners.
There are fundamentally different kinds of centralization. ASICs are extremely special hardware, and their manufacturers NEVER sell them while the mining process by their own ASICs is profitable. So, actual degree of centralization equals to number of ASIC manufacturers in this case. Furthermore, because ASIC manufacturing is a very narrow niche, typically just One ASIC manufacturer of ASICs, designed for specific mining algorithm, remains on the market after short competition wars. Thus degree of centralization become One. Might you know, Bitcoin is heavily centralized, because number of Bitcoin ASICs manufacturers (that ASICs are still effective for mining against current price) ~ 1. We, the Monero community, the Ethereum community, and many other coins' communities, DENY such a degree of centralization. We want every single man can enter the mining market with relatively cheap COMMON equipment to be bought in almost ANY local store right now. Today, common equipment is CPU and GPU. That's all. Of course, low degree of centralization will take place with common equipment too. But the nature of this centralization is conceptually different. That degree depends on (and only on) the Free Desire of Every Single Man to buy COMMON equipment in ANY local store and point it to mine Monero. Historically, before ASICs came to the scene, Monero mining was one of the most DEcentralized among all cryptocurrencies. There are many surveys one can google for. So, "the form of centralized GPU hubs, created by wealthy miners", as you wrote, has much less fundamental kind of centralization than ASIC-based approach. So what about the actual unknown hashrate that dominate all the pools together  I think some engeneers find a solution between FPGA, ASICs and GPU that seems an exotic combination of hardware and software to mine with high hashrate... I'm just looking for an other coin to mine now since this massive unknown hashrate arrive...to broke centralization, as you wrote... |
|
|
|
I'm just a small GPU XMR miner since several month, and the last time I saw such a strong rise in hashrate was when bitmain mined in secret with theirs asics only known by them. It seems that they are re-offending. In less than 48 hours 60% of the hashrate is unknown ! Houston, we have a problem    The hashrate has more than doubled in less than two weeks! Something is happening. Either a 51% attack occurs, or specific asics are minning on the network recently. Is it that the most seasoned supervisors of the monero blockchain can confirm or deny what appears to be an attack ? Sorry for my English translated with google translate. |
|
|
|
We are working with Foreman team to have a seamless Foreman Dashboard experience with nvOC, You can check Foreman thread and Foreman Dashboard to see how it works or install it manually until our next release. What a good news ! This project looks like very good. nvOC will win some users with this type of monitor. |
|
|
|
First, only cuda-10 is officially supported by nvidia in ubuntu 18.
Second, this new image fills the gap in having a dual cuda image ready to load on your disk, the previous ubuntu 16 image included cuda-8 only.
Third, more than a thing is not working at its best in ubuntu 18, there are some problems, more or less significant with curl, tempcontrol and compilation in general because of the updated gcc suite.
In short, as long as you run miners designed for cuda 8/9 I recommend to go with ubuntu 16. Te other images are still valid, it's all up to your preferences or experiences.
Thanks for theses explanations details Lukepicci. As i said in my last message, i will install it after i synchronized my XMR wallet with his new CNV8 blockchain database |
|
|
|
nvOC_19-3.x, Ubuntu 16.04, Dual-Cuda 8+9.2, Nvidia 410, 2018-10-27 Download Link Why come back to version 16.04 of ubuntu? What was the problem with version 18.04? I admit that for my part, I did not appreciate the problem of DNS that takes too much time to synchronize properly. As soon as I finish syncing my Monero wallet I download it and install it on a new disk. The idea of a 1 bash.template lite is good, I complete my 1 bash faster this way. Translated from French with Google translation and not re-read for correction. |
|
|
|
Where can we find 3.0 image?
There is not an image. You have to use precedent ISO and use git to push 3.0 new stable branch on your system in another folder near from mining folder from 19.2.1. I had to learn to use git but it is not very complicated. On the other hand you will have to recompile all the minning software and for my part, the papampi script did not work. It downloads the sources from github, from the dedicated page, but can not properly compile the mining software in stride. And XMR-Stak seems to be slower once compiled by hand. I guess it's due to cryptonight v8, but we'd have to see if other mining software is more efficient. Too bad because I appreciate Xmr-Stak which is very stable. I was doing 6.5 KHs, and I lost about 1 to 1.5 KHs. I now have 4.5 to 5KHs :-( Note that I have not tried to push the overcloking as on the previous version. I realized that paradoxically I was wasting power overclocking and I had a big difference between the pool and the software display. What does not seem to be the case with this new version. Si i will try again to overclock and verify if the pool display the same hashrate with OC. My pool for monero is pool.supportxmr.com. the second in hashrate power. Note : th tx cost must be lower with this bulleproof and POW hard fork, but i don't verified yet. If someone can confirm, with a tx address, i accept to see it. I still can not get auto start XMR-stak running with all scripts as it should. For some reasons unknown to me, I was able to launch it by hand yesterday, but not via nvOC scripts. Another problem, from the system this time, is about DNS resolution. Systemd took control of the name resolution and it works very badly for me. Ubuntu loose more than 10 minutes before finding a normal name resolution. grrrrrrr As soon as I put the nameserver in the resolv.conf file everything works fine immediately. Except for every startup, the resolv.conf file is restored by default without the line I added. grrrr I wonder about the usefulness of having done so in ubuntu 18.04 ... LukePicci or Papampi Can you give us back, or remember the links and procedures to install the new version without rewriting a complete image on the disk? Translated from French with Google translation and not re-read for correction. |
|
|
|
ANother release from xmr-stak : 2.5.1 https://github.com/fireice-uk/xmr-stak/releasesHow To compile xmr-stak : https://github.com/fireice-uk/xmr-stak/blob/master/doc/compile_Linux.mdThis release supports the cryptonight_v8 POW of the upcoming Monero fork on 18th Oct 2018.
Use the currency setting monero for automatic switching on the next fork.
A bug which broke AMD HD6XXX GPUs is fixed.
We dropped NVIDIA Fermi support in the precompiled Windows binaries. The minimum required CUDA Version for NVIDIA GPUs is 9.0.
The precompiled binaries includes OpenSSL 1.1.1 for a better TLS compatibility.
You can now use with AMD Rocm 1.9.X.
Config files from 2.5.0 are compatible and 2.4.X or older are NOT compatible to this release.
We would like to thank the community for their tests and contributions to xmr-stak.
Changelog:
Add console warning on GPU error. #1956
update AMD install docu #1954
Remove dead code #1950
Add missing test for cryptonight_lite #1949
fix broken AMD OpenCL compile #1945 #1951
reduce blocking during metric update #1940
fix access uninitialized value #1928
Just made a PR, will be merged to release point soon I managed to compile it on nvOC dual_CUDA. But I'm not sure he's using version 9.2 when compiling. I have not managed to correctly integrate this xmr-stak new version (5.1) in the 0miner script by modifying only a few simple lines to launch the minning logie. So I launched the software by hand after launching the terminal that loads the other scripts like tempcontrol, watchdog, wtm_check profit or log_rotate. Since the software was not starting correctly via 3main, I just closed the minning terminal and launched a new unamaed tab to run xmr-stak manually with the right command. I noticed a sharp drop in speed compared to cryptonight V7 although the network lost about 1/3 of its power because of the fork. perhaps CNv8 is more heavy to calculate. I don't know. I hope that Freice and psychocrypt will optimize all this soon because I mined at 6 KH/s to 5 KH/s or below !  I saw on github that you are working on the next version 3.0 of nvOC. It is a very good news. Translated with google translation |
|
|
|
Hi!
Has been trying to mine RVN (x16r) with suprnova few times
but for some reason ZENEMYminer doesn't start at all.
Can anyone help with it?
I think you will have more answers on discord or github |
|
|
|
|
On the occasion of the new passage to the V8 cryptonight, the web page has been updated daily. I infer that the administrator monitors his mining pool more than what is said in previous comments.
I would not go back to mining here because it would be too long to get my winnings, and besides I see that the promises are not kept since I still have not seen anything coming for XMV. No information on the page of the pool, nor messages on this forum.
I advise against mining here, as said superrésistant previously, if you do not have at least 10 KH / s to hope to recover your earnings quickly.
But also because it seems that the admin of this pool is pretty heavily antisocial to never answer any questions from the top of his computer engineering superiority probably developer.
I chose supportxmr and I am very satisfied. Their direct competitor also seems very satisfied. Check the list of monero pools on their website. it is not worth it and make your choice.
Translated from French with Google translation
|
|
|
|
ANother release from xmr-stak : 2.5.1 https://github.com/fireice-uk/xmr-stak/releasesHow To compile xmr-stak : https://github.com/fireice-uk/xmr-stak/blob/master/doc/compile_Linux.mdThis release supports the cryptonight_v8 POW of the upcoming Monero fork on 18th Oct 2018.
Use the currency setting monero for automatic switching on the next fork.
A bug which broke AMD HD6XXX GPUs is fixed.
We dropped NVIDIA Fermi support in the precompiled Windows binaries. The minimum required CUDA Version for NVIDIA GPUs is 9.0.
The precompiled binaries includes OpenSSL 1.1.1 for a better TLS compatibility.
You can now use with AMD Rocm 1.9.X.
Config files from 2.5.0 are compatible and 2.4.X or older are NOT compatible to this release.
We would like to thank the community for their tests and contributions to xmr-stak.
Changelog:
Add console warning on GPU error. #1956
update AMD install docu #1954
Remove dead code #1950
Add missing test for cryptonight_lite #1949
fix broken AMD OpenCL compile #1945 #1951
reduce blocking during metric update #1940
fix access uninitialized value #1928
|
|
|
|
|
Show Posts
