Pages:
Author

Topic: [OS] nvOC easy-to-use Linux Nvidia Mining (Read 417954 times)

full member
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
April 08, 2019, 02:50:20 AM

nvOC Community Release is moving to its own thread

Please post your questions, comments, ... in new thread

[OS] nvOC Community Release free-easy-to-use Linux Nvidia Mining


newbie
Activity: 96
Merit: 0
How do i use the trex miner for RVN ? i see in in folder but its not in 1bash ?

Change:
X16R_MINER="ZENEMYminer"

to:
X16R_MINER="T_Rex"

--
Tigel

Thank you, do you know why i get this :

COIN/ALGO not found, Check your settings
Miner not started, Stopping watchdog

my settings
Code:
COIN="RVN"

# Raven Coin (RVN)
RVN_ADDRESS="infowire.RVNMiner1"
RVN_EXTENSION_ARGUMENTS="-p x -a x16r"
RVN_POOL="rvn.suprnova.cc"
RVN_PORT="6666"
RVN_WORKER="$WORKERNAME"

Which nvOC version are you using?

Is X16R coins set in 1bash?

Code:
X16R_COINS="RVN"





Code:
X16R_COINS="RVN,XMN"


nvOC_19-3.x_U16.04_Cuda_8-9.2_N410_2018-10-27
full member
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
How do i use the trex miner for RVN ? i see in in folder but its not in 1bash ?

Change:
X16R_MINER="ZENEMYminer"

to:
X16R_MINER="T_Rex"

--
Tigel

Thank you, do you know why i get this :

COIN/ALGO not found, Check your settings
Miner not started, Stopping watchdog

my settings
Code:
COIN="RVN"

# Raven Coin (RVN)
RVN_ADDRESS="infowire.RVNMiner1"
RVN_EXTENSION_ARGUMENTS="-p x -a x16r"
RVN_POOL="rvn.suprnova.cc"
RVN_PORT="6666"
RVN_WORKER="$WORKERNAME"

Which nvOC version are you using?

Is X16R coins set in 1bash?

Code:
X16R_COINS="RVN"
newbie
Activity: 96
Merit: 0
How do i use the trex miner for RVN ? i see in in folder but its not in 1bash ?

Change:
X16R_MINER="ZENEMYminer"

to:
X16R_MINER="T_Rex"

--
Tigel

Thank you, do you know why i get this :

COIN/ALGO not found, Check your settings
Miner not started, Stopping watchdog

my settings
Code:
COIN="RVN"

# Raven Coin (RVN)
RVN_ADDRESS="infowire.RVNMiner1"
RVN_EXTENSION_ARGUMENTS="-p x -a x16r"
RVN_POOL="rvn.suprnova.cc"
RVN_PORT="6666"
RVN_WORKER="$WORKERNAME"
newbie
Activity: 66
Merit: 0
Is RadeonVII supported?

Nope, it's Nvidia only.

--
Tigel
jr. member
Activity: 279
Merit: 1
Is RadeonVII supported?
newbie
Activity: 66
Merit: 0
How do i use the trex miner for RVN ? i see in in folder but its not in 1bash ?

Change:
X16R_MINER="ZENEMYminer"

to:
X16R_MINER="T_Rex"

--
Tigel
newbie
Activity: 96
Merit: 0
How do i use the trex miner for RVN ? i see in in folder but its not in 1bash ?
full member
Activity: 340
Merit: 103
It is easier to break an atom than partialities AE

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.
full member
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!

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.


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.
full member
Activity: 340
Merit: 103
It is easier to break an atom than partialities AE

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.
full member
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!

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.
member
Activity: 112
Merit: 13
If you'd like to see how a Foreman dashboard looks, we just released a public read-only demo account that you can access here:  https://dashboard.foreman.mn/demo/
full member
Activity: 340
Merit: 103
It is easier to break an atom than partialities AE

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

Code:
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.
full member
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!

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

Code:
m1@m1-desktop:~$ cat /usr/local/cuda/version.txt
CUDA Version 9.2.148


Have you tried beta_testing: bash nvOC miners-upgrade
Then let it recompile XMR_Stak?

full member
Activity: 340
Merit: 103
It is easier to break an atom than partialities AE
I have a problem from several month with xmr-stak :

When xmr-stak start, i can read theses messages :

Quote
[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 :

Quote
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 :

Quote
[ 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 :

Quote
:~/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 ?
full member
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!
19-3.1 Community Release beta_testing progress:

Code:
Fixed Foreman integration
Fixed Claymore and PhoenixMiner GPU selection
Fixed a problem in updating miners
All miners updated to latest
Added NBMiner


Available Miners:
  • BMINER
  • CLAYMORE
  • CryptoDredge
  • DSTM
  • ENERGIMINER
  • ETHMINER
  • EWBF
  • GMINER
  • LOLMINER
  • NBMiner
  • PhoenixMiner
  • tpruvot ccminer
  • T_Rex
  • XMR_Stak
  • ZENEMY miner
  • Z_EWBF
  • cpuOPT
full member
Activity: 686
Merit: 140
Linux FOREVER! Resistance is futile!!!

............

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) :

...........




Thanks for detailed howto

From next release with pluggable miners you dont need to edit 0miner or any other scripts, just need 3 sections bellow, add new algo to algos,  newalgo_coins and newalgo_miner info to 1bash and all is set.


Code:
ALGOS=" .... CRYPTONIGHTR ....  "

Code:
CRYPTONIGHTR_COINS=" ... "

Code:
CRYPTONIGHTR_INTENSITY="5"
CRYPTONIGHTR_MINER="XMR_Stak"
CRYPTONIGHTR_WALLET_FORMAT="$WALLET_ADDRESS_FORMAT"
full member
Activity: 340
Merit: 103
It is easier to break an atom than partialities AE
Code:
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

Code:
sudo vi donate-level.hpp

Code:
:wq!

Code:
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

Code:
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
Code:
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]
full member
Activity: 340
Merit: 103
It is easier to break an atom than partialities AE
Monero Fork in approach : https://bitcointalksearch.org/topic/m.49737084

New xmr-stak 2.8.3 with new consensus : https://github.com/fireice-uk/xmr-stak/releases/latest

I will try it for now and returns you if i have some difficulties.

Another news about monero algo fork and my favorite miner xmr-stak :

https://github.com/fireice-uk/xmr-stak/releases/tag/2.9.0

Quote
This 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
Pages:
Jump to: