[OS] nvOC easy-to-use Linux Nvidia Mining - page 16.

Bibi187

full member

Activity: 420

Merit: 106

https://steemit.com/@bibi187

Hey

It seems i have a weird issue ...

When using 3main to ETH it seems that launching autotemp control ...

When i choice another based on ETHASH everything is working fine ...

As example my 3main file working for ATH but not for ETH, 3main don't even launch the miner.

3main sample :

if [ $COIN == "ATH" ]
then
HCD='/home/m1/eth/ethminer_12dev2/ethminer'
ATHADDR="$ATH_ADDRESS.$ATH_WORKER"

fi

screen -dmSL miner $HCD --farm-recheck 200 -U -S $ATH_POOL -SP 1 -O $ATHADDR

if [ $LOCALorREMOTE == "LOCAL" ]
then
screen -r miner
fi

if [ $LOCALorREMOTE == "LOCAL" ]
then
screen -r miner
fi

BITCOIN="theGROUND"

while [ $BITCOIN == "theGROUND" ]
do
sleep 60
done
fi

if [ $COIN == "ETH" ]
then

HCD='/home/m1/eth/ethminer_12dev2/ethminer'
ETHADDR="$ETH_ADDRESS/$ETH_WORKER"

fi

screen -dmSL miner $HCD -S $ETH_POOL -O $ETHADDR:x -U

if [ $LOCALorREMOTE == "LOCAL" ]
then
screen -r miner
fi

BITCOIN="theGROUND"

while [ $BITCOIN == "theGROUND" ]
do
sleep 60
done
fi

Here is my 1bash extract :

ETH_WORKER="$WORKERNAME"
ETH_ADDRESS="MyAddress"
ETH_POOL="eth-eu1.nanopool.org:9999"

ATH_WORKER="$WORKERNAME"
ATH_ADDRESS="MyAddress"
ATH_POOL="geo.pool.atheios.eu:8001"

So really weird when i select ATH everything is working fine miner launch etc ... When i select ETH instant of miner launch on screen -x miner, i get another temp control session ...

I think i finally have to go on the new version Cheesy

papampi_2

jr. member

Activity: 112

Merit: 3

Linux Forever... Resistance is futile!!!

fk2

jr. member

Activity: 67

Merit: 2

@papampi: tyvm for quick support on watchdog! already pulled latest version but stucked on cuda update.

I did an update following this guide: https://wagonhelm.github.io/articles/2018-02/Installing-Cuda-9.0-Toolkit-Ubuntu-16.04
I installed 9.2 and skipped cudNN. I did the last two steps udating bash file and terminal.

Code:

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

I recompiled KTccminer plus KTccminer-cryptonight, unfortunately not everything was saved properly, the first KTccminer lines are missing but it looked good:

Code:

ptxas info    : Used 157 registers, 256 bytes smem, 344 bytes cmem[0]
ptxas info    : Compiling entry function '_Z33neoscrypt_gpu_hash_salsa2_stream1jj' for 'sm_37'
ptxas info    : Function properties for _Z33neoscrypt_gpu_hash_salsa2_stream1jj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 132 registers, 328 bytes cmem[0]
ptxas info    : Compiling entry function '_Z33neoscrypt_gpu_hash_salsa1_stream1jj' for 'sm_37'
ptxas info    : Function properties for _Z33neoscrypt_gpu_hash_salsa1_stream1jj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 90 registers, 328 bytes cmem[0]
ptxas info    : Compiling entry function '_Z34neoscrypt_gpu_hash_chacha2_stream1jj' for 'sm_37'
ptxas info    : Function properties for _Z34neoscrypt_gpu_hash_chacha2_stream1jj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 132 registers, 328 bytes cmem[0]
ptxas info    : Compiling entry function '_Z34neoscrypt_gpu_hash_chacha1_stream1jj' for 'sm_37'
ptxas info    : Function properties for _Z34neoscrypt_gpu_hash_chacha1_stream1jj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 91 registers, 328 bytes cmem[0]
ptxas info    : Compiling entry function '_Z24neoscrypt_gpu_hash_startijj' for 'sm_37'
ptxas info    : Function properties for _Z24neoscrypt_gpu_hash_startijj
    320 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 236 registers, 256 bytes smem, 332 bytes cmem[0]
ptxas info    : 88 bytes gmem, 1088 bytes cmem[3]
ptxas info    : Compiling entry function '_Z21get_cuda_arch_neo_gpuPi' for 'sm_70'
ptxas info    : Function properties for _Z21get_cuda_arch_neo_gpuPi
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 6 registers, 360 bytes cmem[0]
ptxas info    : Compiling entry function '_Z25neoscrypt_gpu_hash_endingijjPj' for 'sm_70'
ptxas info    : Function properties for _Z25neoscrypt_gpu_hash_endingijjPj
    64 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 128 registers, 256 bytes smem, 376 bytes cmem[0], 8 bytes cmem[2]
ptxas info    : Compiling entry function '_Z33neoscrypt_gpu_hash_salsa2_stream1jj' for 'sm_70'
ptxas info    : Function properties for _Z33neoscrypt_gpu_hash_salsa2_stream1jj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 136 registers, 360 bytes cmem[0]
ptxas info    : Compiling entry function '_Z33neoscrypt_gpu_hash_salsa1_stream1jj' for 'sm_70'
ptxas info    : Function properties for _Z33neoscrypt_gpu_hash_salsa1_stream1jj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 92 registers, 360 bytes cmem[0]
ptxas info    : Compiling entry function '_Z34neoscrypt_gpu_hash_chacha2_stream1jj' for 'sm_70'
ptxas info    : Function properties for _Z34neoscrypt_gpu_hash_chacha2_stream1jj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 136 registers, 360 bytes cmem[0]
ptxas info    : Compiling entry function '_Z34neoscrypt_gpu_hash_chacha1_stream1jj' for 'sm_70'
ptxas info    : Function properties for _Z34neoscrypt_gpu_hash_chacha1_stream1jj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 92 registers, 360 bytes cmem[0]
ptxas info    : Compiling entry function '_Z24neoscrypt_gpu_hash_startijj' for 'sm_70'
ptxas info    : Function properties for _Z24neoscrypt_gpu_hash_startijj
    320 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 95 registers, 256 bytes smem, 364 bytes cmem[0], 8 bytes cmem[2]
ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
ptxas info    : 0 bytes gmem, 4224 bytes cmem[3]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_80jjPv' for 'sm_52'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_80jjPv
    16 bytes stack frame, 24 bytes spill stores, 28 bytes spill loads
ptxas info    : Used 64 registers, 4096 bytes smem, 336 bytes cmem[0], 76 bytes cmem[2]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_64jPj' for 'sm_52'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_64jPj
    40 bytes stack frame, 48 bytes spill stores, 52 bytes spill loads
ptxas info    : Used 64 registers, 4096 bytes smem, 336 bytes cmem[0], 84 bytes cmem[2]
ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
ptxas info    : 0 bytes gmem, 4224 bytes cmem[3]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_80jjPv' for 'sm_50'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_80jjPv
    16 bytes stack frame, 24 bytes spill stores, 28 bytes spill loads
ptxas info    : Used 64 registers, 4096 bytes smem, 336 bytes cmem[0], 76 bytes cmem[2]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_64jPj' for 'sm_50'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_64jPj
    40 bytes stack frame, 48 bytes spill stores, 52 bytes spill loads
ptxas info    : Used 64 registers, 4096 bytes smem, 336 bytes cmem[0], 84 bytes cmem[2]
ptxas info    : 0 bytes gmem, 4224 bytes cmem[3]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_80jjPv' for 'sm_37'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_80jjPv
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 126 registers, 4096 bytes smem, 336 bytes cmem[0]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_64jPj' for 'sm_37'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_64jPj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 126 registers, 4096 bytes smem, 336 bytes cmem[0]
ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
ptxas info    : 0 bytes gmem, 4224 bytes cmem[3]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_80jjPv' for 'sm_35'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_80jjPv
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 64 registers, 4096 bytes smem, 336 bytes cmem[0]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_64jPj' for 'sm_35'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_64jPj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 64 registers, 4096 bytes smem, 336 bytes cmem[0]
ptxas warning : Too big maxrregcount value specified 128, will be ignored
ptxas info    : 0 bytes gmem, 4224 bytes cmem[3]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_80jjPv' for 'sm_30'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_80jjPv
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 63 registers, 4096 bytes smem, 336 bytes cmem[0], 4 bytes cmem[2]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_64jPj' for 'sm_30'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_64jPj
    0 bytes stack frame, 0 bytes spill stores, 0 bytes spill loads
ptxas info    : Used 63 registers, 4096 bytes smem, 336 bytes cmem[0]
ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
ptxas info    : Overriding global maxrregcount 128 with entry-specific value 64 computed using thread count
ptxas info    : 0 bytes gmem, 4224 bytes cmem[3]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_80jjPv' for 'sm_70'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_80jjPv
    48 bytes stack frame, 76 bytes spill stores, 96 bytes spill loads
ptxas info    : Used 64 registers, 4096 bytes smem, 368 bytes cmem[0], 8 bytes cmem[2]
ptxas info    : Compiling entry function '_Z26x11_shavite512_gpu_hash_64jPj' for 'sm_70'
ptxas info    : Function properties for _Z26x11_shavite512_gpu_hash_64jPj
    56 bytes stack frame, 92 bytes spill stores, 104 bytes spill loads
ptxas info    : Used 64 registers, 4096 bytes smem, 368 bytes cmem[0], 8 bytes cmem[2]
g++  -O3 -march=native -std=c++11 -pthread -fno-strict-aliasing -pthread -L/usr/local/cuda/lib64 -ldl  -o ccminer ccminer-crc32.o ccminer-hefty1.o ccminer-ccminer.o ccminer-util.o ccminer-api.o ccminer-hashlog.o ccminer-stats.o ccminer-sysinfos.o ccminer-cuda.o ccminer-nvml.o ccminer-nvsettings.o sph/ccminer-neoscrypt.o sph/ccminer-sha256_Y.o sph/ccminer-sph_sha2.o ccminer-fuguecoin.o Algo256/cuda_fugue256.o sph/ccminer-fugue.o ccminer-groestlcoin.o cuda_groestlcoin.o ccminer-myriadgroestl.o cuda_myriadgroestl.o lyra2/ccminer-Lyra2.o lyra2/ccminer-Sponge.o lyra2/lyra2REv2.o lyra2/cuda_lyra2v2.o Algo256/cuda_blake256.o Algo256/cuda_groestl256.o Algo256/cuda_keccak256.o Algo256/cuda_skein256.o Algo256/cuda_bmw256.o Algo256/cuda_cubehash256.o Algo256/blake256.o Algo256/keccak256.o JHA/jackpotcoin.o JHA/cuda_jha_keccak512.o JHA/cuda_jha_compactionTest.o cuda_checkhash.o quark/cuda_jh512.o quark/cuda_quark_blake512.o quark/cuda_quark_groestl512.o quark/cuda_skein512.o quark/cuda_bmw512.o quark/cuda_quark_keccak512.o quark/cuda_jh512keccak512.o quark/quarkcoin.o quark/cuda_quark_compactionTest.o cuda_nist5.o pentablake.o skein.o Sia/sia.o Sia/cuda_sia.o sph/ccminer-bmw.o sph/ccminer-blake.o sph/ccminer-groestl.o sph/ccminer-jh.o sph/ccminer-keccak.o sph/ccminer-skein.o sph/ccminer-cubehash.o sph/ccminer-echo.o sph/ccminer-luffa.o sph/ccminer-sha2.o sph/ccminer-shavite.o sph/ccminer-simd.o sph/ccminer-hamsi.o sph/ccminer-hamsi_helper.o sph/ccminer-shabal.o sph/ccminer-whirlpool.o sph/ccminer-sha2big.o sph/ccminer-haval.o qubit/qubit.o qubit/qubit_luffa512.o qubit/deep.o qubit/doom.o x11/x11.o x11/fresh.o x11/cuda_x11_luffa512.o x11/cuda_x11_cubehash512.o x11/cuda_x11_shavite512.o x11/cuda_x11_simd512.o x11/cuda_x11_echo.o x11/cuda_x11_luffa512_Cubehash.o x13/x13.o x13/cuda_x13_hamsi512.o x13/cuda_x13_fugue512.o x15/x14.o x15/x15.o x15/cuda_x14_shabal512.o x15/cuda_x15_whirlpool.o x15/whirlpool.o x17/x17.o x17/cuda_x17_haval512.o x17/cuda_x17_sha512.o x11/s3.o x11/c11.o bitcoin.o cuda_bitcoin.o x15/cuda_whirlpoolx.o x15/whirlpoolx.o neoscrypt/neoscrypt.o neoscrypt/cuda_neoscrypt.o neoscrypt/cuda_neoscrypt_tpruvot.o -L/usr/lib/x86_64-linux-gnu -lcurl -ljansson -lpthread  -lcudart -fopenmp -lcrypto -lssl  -ldl -lcrypto -lssl
make[2]: Leaving directory '/home/m1/NVOC/testing/miners/KTccminer/src'
make[1]: Leaving directory '/home/m1/NVOC/testing/miners/KTccminer/src'

Finished compiling KlausT ccminer
~/NVOC/testing
m1@m1-desktop:~/NVOC/testing$ sudo bash nvOC miners-upgrade
root@m1-desktop:~$nvOC miners-upgrade
Checking for nvOC miners updates...
Submodule path 'miners': checked out 'cdc0910c7257d245d045fd43643cad68ee8037cb'
Running updates installer
~/NVOC/testing ~/NVOC/testing
Updating miners for nvOC V0019-2.1
Will check and restart miner if needed

Checking EWBF Equihash miner
EWBF Equihash miner is already up-to-date

Checking EWBF ZHASH miner
EWBF ZHASH miner is already up-to-date

Checking Equihash DSTM zm miner 0.6.1
DSTM zm miner is already up-to-date

Checking Z-Enemy 1.10
z-enemy is already up-to-date

Checking xmr-stak 2.4.4
xmr-stak is already up-to-date

Checking Silent Miner 1.1.0
Silent Miner is already up-to-date

Checking Claymore v11.9
Claymore is already up-to-date

Checking SP Mod ccminer-1.8.2
SPccminer is already up-to-date

Checking alexis ccminer
ASccminer is already up-to-date

Checking Krnlx ccminer
KXccminer is already up-to-date

Checking Tpruvot ccminer-2.2.5
Tpruvot ccminer is already up-to-date

Checking KlausT ccminer 8.20
KlausT ccminer is already up-to-date

Checking Vertminer v1.0-stable.2 Release
Vertminer is already up-to-date

Checking nanashi-ccminer-2.2-mod-r2
nanashi-ccminer is already up-to-date

Checking Ethminer 0.14.0
ethminer is already up-to-date

Checking KTccminer-cryptonight v2.06
KTccminer-cryptonight is already up-to-date

Checking Equihash Bminer 9.1.0
Extracting Bminer

Checking ANXccminer (git@cd6fab68823e247bb84dd1fa0448d5f75ec4917d)
ANXccminer is already at up-to-date

Checking MSFT Tpruvot ccminer-2.2.5 (RVN)
MSFTccminer is already up-to-date

Checking SUPRminer 1.5
SUPRminer is already up-to-date

Checking cpuminer-opt
cpuminer is already up-to-date


Extracting and checking new miners for nvOC-v0019-2.x finished


Do you want to re-compile your miners (y/N)?  y

Checking if bn.h bignum error is fixed for compiling miners or not
bn.h openssl already fixed for compiling miners

Select miners to compile (multiple comma separated values: 1,6,7)
1 - ASccminer
2 - KTccminer
3 - KTccminer-cryptonight
4 - KXccminer
5 - NAccminer
6 - SPccminer
7 - TPccminer
8 - vertminer
9 - ANXccminer
C - cpuminer
R - MSFTccminer (RVN)
U - SUPRminer
X - xmr-stak

Do your Choice: [A]LL [1] [2] [3] [4] [5] [6] [7] [8] [9] [C] [R] [U] [X] [E]xit: 3
3

Compiling KlausT ccminer cryptonight
 This could take a while ...
Submodule path 'src': checked out '31865e0b846ad98e2ce99aeb9b28bb51d3be22db'
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for gcc option to accept ISO C99... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking whether gcc needs -traditional... no
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for gcc option to support OpenMP... -fopenmp
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking sys/endian.h usability... no
checking sys/endian.h presence... no
checking for sys/endian.h... no
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for sys/sysctl.h... yes
checking whether be32dec is declared... no
checking whether le32dec is declared... no
checking whether be32enc is declared... no
checking whether le32enc is declared... no
checking for size_t... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for getopt_long... yes
checking whether we can compile AVX code... yes
checking whether we can compile XOP code... yes
checking whether we can compile AVX2 code... yes
checking for json_loads in -ljansson... yes
checking for pthread_create in -lpthread... yes
checking for SSL_library_init in -lssl... yes
checking for EVP_DigestFinal_ex in -lcrypto... yes
checking for gawk... (cached) gawk
checking for curl-config... /usr/bin/curl-config
checking for the version of libcurl... 7.47.0
checking for libcurl >= version 7.15.2... yes
checking whether libcurl is usable... yes
checking for curl_free... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating compat/Makefile
config.status: creating compat/jansson/Makefile
config.status: creating cpuminer-config.h
config.status: executing depfiles commands
bash: /home/m1/NVOC/testing/miners/KTccminer-cryptonight/src/build.sh: No such file or directory
cp: cannot stat '/home/m1/NVOC/testing/miners/KTccminer-cryptonight/src/ccminer': No such file or directory

Finished compiling KlausT ccminer cryptonight
~/NVOC/testing
m1@m1-desktop:~/NVOC/testing$ sudo reboot -f

Now starting NICE-CRYPTONIGHT:

Code:

m1@m1-desktop:~$nvOC miner-log
/home/m1/NVOC/testing/miners/KTccminer-cryptonight/ccminer: error while loading shared libraries: libcudart.so.8.0: cannot open shared object file: No such file or directory

rig rebooting after some time so I guess the patched watchdog is working

edit: I tried some more NICE_ETHASH meanwhile. Can't get ethminer running, I tried Claymore 11.9 again. I always end up with the very first problem, no matter what argument I add to NICE_ETHASH:

Code:

����������������������������������������������������������������ͻ
�                Claymore's Dual GPU Miner - v11.9               �
�              ETH + DCR/SIA/LBC/PASC/BLAKE2S/KECCAK             �
����������������������������������������������������������������ͼ

ETH: 1 pool is specified
Main Ethereum pool is daggerhashimoto.usa.nicehash.com:3353
AMD OpenCL platform not found
Be careful with overclocking, use default clocks for first tests
Press "s" for current statistics, "0".."9" to turn on/off cards, "r" to reload pools, "e" or "d" to select current pool, "x" to select GPU
CUDA initializing...

NVIDIA Cards available: 5
CUDA Driver Version/Runtime Version: 9.2/8.0
GPU #0: GeForce GTX 1080 Ti, 11177 MB available, 28 compute units, capability: 6.1  (pci bus 1:0:0)
GPU #1: GeForce GTX 1080 Ti, 11178 MB available, 28 compute units, capability: 6.1  (pci bus 2:0:0)
GPU #2: GeForce GTX 1080 Ti, 11178 MB available, 28 compute units, capability: 6.1  (pci bus 4:0:0)
GPU #3: GeForce GTX 1080, 8119 MB available, 20 compute units, capability: 6.1  (pci bus 5:0:0)
GPU #4: GeForce GTX 1080, 8119 MB available, 20 compute units, capability: 6.1  (pci bus 7:0:0)
Total cards: 5

You can use "+" and "-" keys to achieve best ETH speed, see "FINE TUNING" section in Readme for details.

ETH: Stratum - connecting to 'daggerhashimoto.usa.nicehash.com' <172.65.194.252> port 3353 (unsecure)
ETH: Stratum - Connected (daggerhashimoto.usa.nicehash.com:3353) (unsecure)
ETHEREUM-ONLY MINING MODE ENABLED (-mode 1)
ETH: miner-proxy stratum mode
"-allpools" option is set, default pools can be used for devfee, check "Readme" file for details.
Watchdog enabled
Remote management (READ-ONLY MODE) is enabled on port 3333

ETH: Authorized
cannot convert blob3 data
cannot convert blob3 data
cannot convert blob3 data
cannot convert blob3 data
ETH: Job timeout, disconnect, retry in 20 sec...

I tried following arguments:
NICE_ETHASH_EXTENSION_ARGUMENTS="-esm 3 -allpools 1 -estale 0"
NICE_ETHASH_EXTENSION_ARGUMENTS="-esm 2 -allpools 1 -estale 0"
NICE_ETHASH_EXTENSION_ARGUMENTS="-esm 2 -allpools 1"
NICE_ETHASH_EXTENSION_ARGUMENTS="-allpools 1"

error remains the same. Is anybody using any NICEHASH with nvOC 2.1 successfully?

gs777

member

Activity: 118

Merit: 10

Looks like somebody hacked his account and using random text generator

papampi_2

jr. member

Activity: 112

Merit: 3

Linux Forever... Resistance is futile!!!

Quote from: Muhammadaffandi10 on August 05, 2018, 09:40:06 AM

Quote from: newmz on April 15, 2017, 06:21:27 AM

This is all very interesting to me because I currently use Windows 8.1 for my Nvidia Rig but in the past I have mined with my AMD rigs using EthOS and found it much more stable and reliable, and using much lower resources, etc - so a Linux solution for an Nvidia rig sounds great. I was considering trying the PiMP Nvidia version but when I tried that for my AMD rigs it confused the hell out of me.

Anyway, I have one big question because it doesn't seem clear to me from the small amount of info in this thread whether it will suit my rig. Reason being, my rig is currently 2 x Gigabyte gtx1070 G1 Gaming cards and 2 x Galax gtx 1060 6GB cards.

It seems from what I read above that when you set cc & mc overclock and powerlimit - this is one setting to apply to all cards on the rig. This is obviously suitable for the typical situation where people commonly use multiple instances of 1 type of card on a rig, which I understand - people choose a GPU, buy however many of them and populate the rig with them.

What about a situation like mine though, where I have 2 of one GPU and 2 of another, so I need to be able to specify different OC and powerlimits for the different cards.

Currently in Windows 8.1 I just use MSI afterburner and set each card individually, so for example I mine ZEC and the 1070s are powerlimited to around 68%, core OC to +70 and mem OC to +700, while the 1060s are powerlimited to about 75%, core OC to +50 and me OC to +500. Using EWBF this is giving me approximately 1400sol/s using 500W at the wall.

Since the powerlimit in Linux seems to be set in watts rather than percent, one setting in a percentage (70% would probably work) but I would need to be able to set the 1070s to around 125W and the 160s to around 85W. The CC could all conceivably be set to +60 and MC to +500 or +600 but is there a way to set powerlimits individually for each card?

yes but convincing the bitcoinner that using windowns depends

you are replying to thread from april 2017 ?

Muhammadaffandi10

member

Activity: 126

Merit: 10

Quote from: newmz on April 15, 2017, 06:21:27 AM

This is all very interesting to me because I currently use Windows 8.1 for my Nvidia Rig but in the past I have mined with my AMD rigs using EthOS and found it much more stable and reliable, and using much lower resources, etc - so a Linux solution for an Nvidia rig sounds great. I was considering trying the PiMP Nvidia version but when I tried that for my AMD rigs it confused the hell out of me.

Anyway, I have one big question because it doesn't seem clear to me from the small amount of info in this thread whether it will suit my rig. Reason being, my rig is currently 2 x Gigabyte gtx1070 G1 Gaming cards and 2 x Galax gtx 1060 6GB cards.

It seems from what I read above that when you set cc & mc overclock and powerlimit - this is one setting to apply to all cards on the rig. This is obviously suitable for the typical situation where people commonly use multiple instances of 1 type of card on a rig, which I understand - people choose a GPU, buy however many of them and populate the rig with them.

What about a situation like mine though, where I have 2 of one GPU and 2 of another, so I need to be able to specify different OC and powerlimits for the different cards.

Currently in Windows 8.1 I just use MSI afterburner and set each card individually, so for example I mine ZEC and the 1070s are powerlimited to around 68%, core OC to +70 and mem OC to +700, while the 1060s are powerlimited to about 75%, core OC to +50 and me OC to +500. Using EWBF this is giving me approximately 1400sol/s using 500W at the wall.

Since the powerlimit in Linux seems to be set in watts rather than percent, one setting in a percentage (70% would probably work) but I would need to be able to set the 1070s to around 125W and the 160s to around 85W. The CC could all conceivably be set to +60 and MC to +500 or +600 but is there a way to set powerlimits individually for each card?

yes but convincing the bitcoinner that using windowns depends

papampi_2

jr. member

Activity: 112

Merit: 3

Linux Forever... Resistance is futile!!!

Quote from: fk2 on August 04, 2018, 01:42:40 PM

ok, will update cuda and nvidia drivers to latest when i am home again.

but I remember watchdog did reboot idling rigs in the past after a couple of minutes or so. I mean there is even the minimum gpu utilization value in 1bash that came to 1bash when back then it was defaulted to >70% and leaded to rebooting rigs that even mined properly.

I would like to see watchdog do the previous behaviour because idling rigs due to somewhat errors or problems will quickly become unprofitable rigs nowadays

Latest commit will check for miner start one time, restart 3main, gives a warning and continue the watchdog main loop.
So if a card has problem on start it should reboot the rig.

Please, update, test and let us know how it goes.

gs777

member

Activity: 118

Merit: 10

Quote from: papampi_2 on August 04, 2018, 03:10:42 AM

Quote from: gs777 on August 03, 2018, 04:22:10 PM

Guys is it possible to upgrade my EWBF to the latest v0.5 and
Bminer to 9.1.0 (they claim 30% hushing increase)
And how to do it if it's possible
Huh

z_ewbf updated to v0.5, bminer updated to 9.1.0
Run the the nvOC upgrade command:

Code:

bash ~/NVOC/mining/nvOC upgrade

P.S: If your version is too much behind, you may need to run the upgrade command twice and update your 1bash with new 1bash.template

Thank you!
Thank you a lot, v0.5 is working way better then v0.4
more stable and hush rate went up 15%.

papampi_2

jr. member

Activity: 112

Merit: 3

Linux Forever... Resistance is futile!!!

Quote from: fk2 on August 04, 2018, 01:42:40 PM

ok, will update cuda and nvidia drivers to latest when i am home again.

but I remember watchdog did reboot idling rigs in the past after a couple of minutes or so. I mean there is even the minimum gpu utilization value in 1bash that came to 1bash when back then it was defaulted to >70% and leaded to rebooting rigs that even mined properly.

I would like to see watchdog do the previous behaviour because idling rigs due to somewhat errors or problems will quickly become unprofitable rigs nowadays

If miner gives error and wont start, watchdog will not kick in to prevent boot loops and just restart 3main.
But maybe we should add some limits so it restart rig after some 3main restart failed attempts.
Dont think its a good idea, but will check for a solution.

LuKePicci

jr. member

Activity: 128

Merit: 1

The watchdog behavior has not been changed. It is still the same as in 2.0.

In the situation you described rebooting won't solve the idle rig issue, would result in a reboot-loop.

fk2

jr. member

Activity: 67

Merit: 2

ok, will update cuda and nvidia drivers to latest when i am home again.

but I remember watchdog did reboot idling rigs in the past after a couple of minutes or so. I mean there is even the minimum gpu utilization value in 1bash that came to 1bash when back then it was defaulted to >70% and leaded to rebooting rigs that even mined properly.

I would like to see watchdog do the previous behaviour because idling rigs due to somewhat errors or problems will quickly become unprofitable rigs nowadays

LuKePicci

jr. member

Activity: 128

Merit: 1

That is clearly the problem. Mine was just an assumption, didn''t noticed that CRYPTONIGHT is still hardlinked to KTccminer-cryptonight, I assumed it was linked like any other algo you see in that section. I did not take care of that specific part so I would like to know if there are any reason that lead this to be hardlinked. I can easily patch it to work as I assumed but, who knows, maybe someone remember why it has been done that way.

There is a section in 1bash where each coin is linked to its algo, NICE_CRYPTONIGHT is a coin which belongs to the set of CRYPTONIGHT coins.

Your issues with cuda devices not found is probably related to outdated drivers or runtimes, cuda 9.0+ requires nvidia drivers 390+ that's why you find updated drivers in the last prebuilt-image.

The watchdog reboots only when the mining activity is abnormally interrupted, not when the miner never starts.

fk2

jr. member

Activity: 67

Merit: 2

I just realised new problems the last two mornings I checked my testrig:

Code:

m1@m1-desktop:~$nvOC miner-log

ccminer 8.20-KlausT (64bit) for nVidia GPUs
Compiled with GCC 5.4 using Nvidia CUDA Toolkit 8.0

Based on pooler cpuminer 2.3.2 and the tpruvot@github fork
CUDA support by Christian Buchner, Christian H. and DJM34
Includes optimizations implemented by sp-hash, klaust, tpruvot and tsiv.

[2018-08-04 06:46:12] No CUDA device found!

Code:

m1@m1-desktop:~/NVOC/testing$ nvidia-smi
Sat Aug  4 06:49:52 2018
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 387.34                 Driver Version: 387.34                    |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 108...  Off  | 00000000:01:00.0 Off |                  N/A |
|ERR!   36C    P0   ERR! / 170W |     49MiB / 11171MiB |    100%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 108...  Off  | 00000000:02:00.0 Off |                  N/A |
| 50%   30C    P8    11W / 160W |      9MiB / 11172MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   2  GeForce GTX 108...  Off  | 00000000:04:00.0 Off |                  N/A |
| 50%   28C    P8    11W / 160W |      9MiB / 11172MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+
|   3  GeForce GTX 1080    Off  | 00000000:05:00.0 Off |                  N/A |
|ERR!   41C    P0   ERR! / 120W |      9MiB /  8114MiB |    100%      Default |
+-------------------------------+----------------------+----------------------+
|   4  GeForce GTX 1080    Off  | 00000000:07:00.0 Off |                  N/A |
| 50%   31C    P8    12W / 110W |      9MiB /  8114MiB |      0%      Default |
+-------------------------------+----------------------+----------------------+

+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0       912      G   /usr/lib/xorg/Xorg                            31MiB |
|    0      1721      G   compiz                                        13MiB |
|    1       912      G   /usr/lib/xorg/Xorg                             6MiB |
|    2       912      G   /usr/lib/xorg/Xorg                             6MiB |
|    3       912      G   /usr/lib/xorg/Xorg                             6MiB |
|    4       912      G   /usr/lib/xorg/Xorg                             6MiB |
+-----------------------------------------------------------------------------+
m1@m1-desktop:~/NVOC/testing$

Code:

m1@m1-desktop:~$nvOC master-log
==> /home/m1/NVOC/testing/nvoc_logs/screenlog.0 <==

ccminer 8.20-KlausT (64bit) for nVidia GPUs
Compiled with GCC 5.4 using Nvidia CUDA Toolkit 8.0

Based on pooler cpuminer 2.3.2 and the tpruvot@github fork
CUDA support by Christian Buchner, Christian H. and DJM34
Includes optimizations implemented by sp-hash, klaust, tpruvot and tsiv.

[2018-08-04 06:50:43] No CUDA device found!


==> /home/m1/NVOC/testing/nvoc_logs/tempcontrol-screenlog.0 <==
GPU 2:  POWER LIMIT: 160,  TARGET TEMP: 65
GPU 3:  POWER LIMIT: 120,  TARGET TEMP: 65
GPU 4:  POWER LIMIT: 110,  TARGET TEMP: 65

GLOBAL  FAN_ADJUST (%):  5
GLOBAL  POWER_ADJUST (W):  5
GLOBAL  ALLOWED_TEMP_DIFF (C):  2
GLOBAL  RESTORE_POWER_LIMIT (%):  85
GLOBAL  MINIMAL_FAN_SPEED (%):  50


==> /home/m1/NVOC/testing/nvoc_logs/watchdog-screenlog.0 <==
Sat Aug  4 06:47:22 MST 2018 - [WARNING] - Miner not running, reinit nvOC from scratch
Sat Aug  4 06:48:10 MST 2018 - [WARNING] - Miner not running, reinit nvOC from scratch
Sat Aug  4 06:48:55 MST 2018 - [WARNING] - Miner not running, reinit nvOC from scratch
Sat Aug  4 06:49:39 MST 2018 - [WARNING] - Miner not running, reinit nvOC from scratch


Sat Aug  4 06:50:44 MST 2018 - [INFO] - Watchdog is starting

Connection to google.com 443 port [tcp/https] succeeded!
Giving miner enough to stabilize

==> /home/m1/NVOC/testing/nvoc_logs/8_wtmautoswitchlog <==
Miner still not running, waiting ...

Miner still not running, waiting ...

Miner still not running, waiting ...

Miner still not running, waiting ...

Miner still not running, waiting ...


==> /home/m1/NVOC/testing/nvoc_logs/watchdog-screenlog.0 <==
Sat Aug  4 06:51:04 MST 2018 - [WARNING] - Miner not running, reinit nvOC from scratch

==> /home/m1/NVOC/testing/nvoc_logs/8_wtmautoswitchlog <==
Miner still not running, waiting ...

Miner still not running, waiting ...


==> /home/m1/NVOC/testing/nvoc_logs/tempcontrol-screenlog.0 <==
WARNING: Sat Aug  4 06:51:05 MST 2018 - Problem detected! GPU0 is not responding. Will give watchdog 60 seconds to react, if not we will reboot!

Why isn't watchdog rebooting this rig like in the past releases but idling instead for hours?

Quote

Nothing else, I can't say why ktccminer-cryptonight gets launched instead of TPccminer, Make sure you have nothing else in 1bash that could override this settings block.

pretty sure there is nothing else because I did a fresh copy of the v36 temp plus I searched the 1bash file for every NICE_CRPYTONIGHT entry in it.

You and I both don't know why this happen that is because I asked for the definition of NICE_CRYPTONIGHT. Back in earlier releases every selectable coin was just a definition of if coin = x then y

Nowadays it seems to be pointing to only algos like you said. however, a look into my 0miner says:

Code:

## CRYPTONIGHT
elif [[ $ALGO == CRYPTONIGHT ]]
then
  HCD="${NVOC}"/miners/KTccminer-cryptonight/ccminer
  eval $LAUNCH $HCD -o ${!xproto}://"${!xpool}":"${!xport}" -u "${!xaddr}""${!xwallet}""${!xwork}" -p "$MINER_PWD" -i "${!xin$

since I cant find any NICE_CRYPTONIGHT I have to assume somewhere it will point to CRYPTONIGHT. In that case running KTCCM seems to be as designed instead of TPccminer. Is your beta running NICE_CRYPTONIGHT with TPccminer or are you just assuming this should be the case?

papampi_2

jr. member

Activity: 112

Merit: 3

Linux Forever... Resistance is futile!!!

Quote from: gs777 on August 03, 2018, 04:22:10 PM

Guys is it possible to upgrade my EWBF to the latest v0.5 and
Bminer to 9.1.0 (they claim 30% hushing increase)
And how to do it if it's possible
Huh

z_ewbf updated to v0.5, bminer updated to 9.1.0
Run the the nvOC upgrade command:

Code:

bash ~/NVOC/mining/nvOC upgrade

P.S: If your version is too much behind, you may need to run the upgrade command twice and update your 1bash with new 1bash.template

CryptAtomeTrader44

full member

Activity: 340

Merit: 103

It is easier to break an atom than partialities AE

Quote from: gs777 on August 03, 2018, 04:22:10 PM

Guys is it possible to upgrade my EWBF to the latest v0.5 and
Bminer to 9.1.0 (they claim 30% hushing increase)
And how to do it if it's possible
Huh

Download sources from their Githuib and follow compilation instructions gived by devellppers.

gs777

member

Activity: 118

Merit: 10

Guys is it possible to upgrade my EWBF to the latest v0.5 and
Bminer to 9.1.0 (they claim 30% hushing increase)
And how to do it if it's possible
Huh

LuKePicci

jr. member

Activity: 128

Merit: 1

Nothing else, I can't say why ktccminer-cryptonight gets launched instead of TPccminer, Make sure you have nothing else in 1bash that could override this settings block.

fk2

jr. member

Activity: 67

Merit: 2

here are my cryptonight 1bash settings, just in case I get something wrong, also the v7 & heavy ones:

Code:

## CRYPTONIGHT
CRYPTONIGHT_INTENSITY="8"
CRYPTONIGHT_MINER="TPccminer"
CRYPTONIGHT_WALLET_FORMAT="$WALLET_ADDRESS_FORMAT"

## CRYPTONIGHT-V7
CRYPTONIGHTV7_INTENSITY="0"
CRYPTONIGHTV7_MINER="xmr-stak"
CRYPTONIGHTV7_WALLET_FORMAT="$WALLET_ADDRESS_FORMAT"

## CRYPTONIGHTHEAVY
CRYPTONIGHTHEAVY_INTENSITY="0"
CRYPTONIGHTHEAVY_MINER="xmr-stak"
CRYPTONIGHTHEAVY_WALLET_FORMAT="$WALLET_ADDRESS_FORMAT"

If there is anything else defining cryptonight algo-miner selection, let me know

LuKePicci

jr. member

Activity: 128

Merit: 1

@fk2
so, your issue with neoscrypt is that you are unable to compile KTccminer, follow the tip provided by @Schleicher

Miners are assigned per algorithm, so you can't choose a miner for nicehash since it's not an algorithm. You can choose a miner for ethash, neoscrypt or whatever algo, it is all in 1bash.

You have somehow linked KTccminer-cryptonight to cryptonight algo in 1bash, while default miner is TPccminer. Please share your 1bash settings on pastebin. Also, TPccminer does not support intensity 0, set it to a minimum of 8.

Schleicher

hero member

Activity: 675

Merit: 514

Quote from: fk2 on August 01, 2018, 12:55:51 PM

@Luke

I did another 'bash nvOC upgrade' with 'recompile ALL' and upgraded to v36 of 1bash. 'bash nvOC miners-upgrade' tells me every miner is up2date and since I already recompiled all when 'bash nvOC upgrade' I skipped that for now.

NICE_NEOSCRYPT: still the same issue. I tried to recompile KTccminer especially:

Just in case you didn't notice, the compilation failed:

Code:

nvcc fatal   : Unsupported gpu architecture 'compute_70'

That's because you are using CUDA 8.0
There are two methods to fix this: either use CUDA 9.2, or make changes in the Makefile.am:
Remove this line:

Code:

nvcc_ARCH += -gencode=arch=compute_70,code=sm_70

and remove this part of the last line:

Code:

-gencode=arch=compute_70,code=sm_70

Topic: [OS] nvOC easy-to-use Linux Nvidia Mining - page 16. (Read 418244 times)