Is anyone tried EWBF v0.5?
Is it worth to upgrade v0.4
Is it worth to upgrade v0.4
.5 is worth it to upgrade over .4 -- you do actually receive the claimed 2% increase
Topic: [OS] nvOC easy-to-use Linux Nvidia Mining - page 16. (Read 418313 times)
.5 is worth it to upgrade over .4 -- you do actually receive the claimed 2% increase
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
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
@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.
I recompiled KTccminer plus KTccminer-cryptonight, unfortunately not everything was saved properly, the first KTccminer lines are missing but it looked good:
Now starting NICE-CRYPTONIGHT:
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:
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?
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...
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?
Looks like somebody hacked his account and using random text generator
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 dependsAnyway, 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?
you are replying to thread from april 2017 ?
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 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?
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
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.
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
Bminer to 9.1.0 (they claim 30% hushing increase)
And how to do it if it's possible
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%.
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
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.
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.
In the situation you described rebooting won't solve the idle rig issue, would result in a reboot-loop.
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
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
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.
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.
I just realised new problems the last two mornings I checked my testrig:
Why isn't watchdog rebooting this rig like in the past releases but idling instead for hours?
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:
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?
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$
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
Bminer to 9.1.0 (they claim 30% hushing increase)
And how to do it if it's possible
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
full member
Activity: 340
Merit: 103
It is easier to break an atom than partialities AE
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
Bminer to 9.1.0 (they claim 30% hushing increase)
And how to do it if it's possible
Download sources from their Githuib and follow compilation instructions gived by devellppers.
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
Bminer to 9.1.0 (they claim 30% hushing increase)
And how to do it if it's possible
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.
here are my cryptonight 1bash settings, just in case I get something wrong, also the v7 & heavy ones:
If there is anything else defining cryptonight algo-miner selection, let me know
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
@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.
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.
Jump to: