[OS] nvOC easy-to-use Linux Nvidia Mining

[sergixc]

Sure. The easiest way to figure out what functions it supports is to just run it:

Code:

m1@Miner3:~$./nvOC
Usage:  ./nvOC clearlogs
           clears out OS & nvOC logs
        ./nvOC gpuinfo
           displays GPU ID, infomation, settings, and status
        ./nvOC patch
           stops nvOC and applies outstanding Ubuntu patches and
           Nvidia driver updates
        ./nvOC reboot
           reboots the host machine
        ./nvOC stop
           stops mining, watchdog and temperature control
        ./nvOC start
           starts normal nvOC mining operations
        ./nvOC help
           displays help about using and configuring nvOC for mining

The feature that I think will be most useful is gpuinfo which shows what GPUs you have including the settings like power and OC:

Code:

m1@Miner3:~$./nvOC gpuinfo
ID,VENDOR,MODEL,PSTATE,TEMP,FAN,UTILIZATION,POWER,POWERLIMIT,MAXPOWER,GPUCLOCK,MEMCLOCK
--------------------------------------------------------------------------------
0,EVGA,GeForce GTX 1070,P2,48,50,100,113.66,115.00,170.00,1822,4303
1,EVGA,GeForce GTX 1070,P2,41,50,100,86.99,115.00,170.00,1569,4303
2,EVGA,GeForce GTX 1070,P2,54,50,100,112.74,115.00,170.00,1847,4303
3,MSI,GeForce GTX 1080 Ti,P2,68,75,100,243.26,250.00,330.00,1911,5556

The current implementation is not complete. For example, the help function is just stubbed out. We plan to complete this, add more, and refine existing functions in future releases.

Enjoy.

Hi, looks like

Code:

./nvOC stop

works
but

Code:

./nvOC start

does not start anything...nothing going on except the help screen
Could you please check that?

Thank you in advance,
Respectfully,
Serg

[1714489532]

1714489532

[1714489532]

1714489532

[1714489532]

1714489532

[1714489532]

1714489532

[1714489532]

1714489532

[EvgeniX]

who can share their experience with which more profitable mining best coin in current moment or mining one?

This isn't the right thread for that question man, better luck in other threads, especially those that are covering the GPU you are using as there are many different variables that determine this question

Yes and NO

looks like most people who use WTM is using nvOC, thats why I ask here if any one can share their experience

[crazydane]

Either open 3main and edit the 2 lines and add :$XMR_PORT in this section :

Code:

if [ $plusCPU == "YES" ] && [ $AUTO_START_MINER == "YES" ]

Code:

      guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT"
    else
      screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT

Or run the update script again to fix it for you

I edited those 2 lines in 3main and changed 1bash back to the new way with port on a separate line.  The XMR miner now connects to the pool.  However, the miner still exits within 20 seconds of starting for some reason.  The screen window closes immediately when this happens.

[joshuajones02]

who can share their experience with which more profitable mining best coin in current moment or mining one?

This isn't the right thread for that question man, better luck in other threads, especially those that are covering the GPU you are using as there are many different variables that determine this question

Yes and NO

looks like most people who use WTM is using nvOC, thats why I ask here if any one can share their experience

... you're not making any sense. this is still the wrong thread for that question

[papampi]

Either open 3main and edit the 2 lines and add :$XMR_PORT in this section :

Code:

if [ $plusCPU == "YES" ] && [ $AUTO_START_MINER == "YES" ]

Code:

      guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT"
    else
      screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT

Or run the update script again to fix it for you

I edited those 2 lines in 3main and changed 1bash back to the new way with port on a separate line.  The XMR miner now connects to the pool.  However, the miner still exits within 20 seconds of starting for some reason.  The screen window closes immediately when this happens.

Does it quits on remote or local or both?

Restart miner and try to catch the command by :

Code:

ps ax | grep -i pluscpu 

or

Code:

ps ax | grep plusCPU

Copy the output and run it with from /home/m1/ .... to the end in guake terminal to catch if miner quits or some thing else kills it

[crazydane]

Does it quits on remote or local or both?

Restart miner and try to catch the command by :

Code:

ps ax | grep -i pluscpu 

or

Code:

ps ax | grep plusCPU

Copy the output and run it with from /home/m1/ .... to the end in guake terminal to catch if miner quits or some thing else kills it

I don't have a local display attached, I run remote only.  I captured the command that executes and when I execute it from a ssh session, the miner works fine.

Code:

m1@miner06:~$ /home/m1/cpuOPT/cpuminer -a cryptonight -o stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580 -u crazydane.115 -p x -t 10

         **********  cpuminer-opt 3.6.3  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0, Jeff Garzik and Optiminer.

CPU: Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz
CPU features: SSE2 AES AVX AVX2
SW built on May 18 2017 with GCC 5.4.0
SW features: SSE2
Algo features: SSE2 AES
Start mining with SSE2

[2017-12-11 12:45:25] Starting Stratum on stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580
[2017-12-11 12:45:25] 10 miner threads started, using 'cryptonight' algorithm.
[2017-12-11 12:45:26] Stratum difficulty set to 500054
[2017-12-11 12:45:29] CPU #4: 66 H, 28.78 H/s
[2017-12-11 12:45:30] CPU #5: 66 H, 28.43 H/s
[2017-12-11 12:45:31] CPU #0: 66 H, 19.10 H/s
[2017-12-11 12:45:31] CPU #1: 66 H, 18.81 H/s
[2017-12-11 12:45:31] CPU #2: 66 H, 18.74 H/s
[2017-12-11 12:45:31] CPU #3: 66 H, 18.53 H/s
[2017-12-11 12:45:31] CPU #7: 66 H, 18.11 H/s
[2017-12-11 12:45:31] CPU #8: 66 H, 17.94 H/s
[2017-12-11 12:45:31] CPU #9: 66 H, 17.73 H/s
[2017-12-11 12:45:31] CPU #6: 66 H, 15.76 H/s
[2017-12-11 12:45:44] CPU #8: 250 H, 18.93 H/s
[2017-12-11 12:45:44] CPU #0: 267 H, 19.87 H/s
[2017-12-11 12:45:44] CPU #3: 262 H, 19.65 H/s
[2017-12-11 12:45:44] CPU #1: 264 H, 19.71 H/s
[2017-12-11 12:45:44] CPU #4: 447 H, 30.59 H/s
[2017-12-11 12:45:44] CPU #9: 250 H, 18.96 H/s
[2017-12-11 12:45:44] CPU #5: 441 H, 30.21 H/s
[2017-12-11 12:45:44] CPU #2: 263 H, 19.62 H/s
[2017-12-11 12:45:44] CPU #6: 208 H, 16.32 H/s
[2017-12-11 12:45:44] CPU #7: 252 H, 18.97 H/s
[2017-12-11 12:46:39] Stratum difficulty set to 350009
[2017-12-11 12:46:39] CPU #8: 1046 H, 18.90 H/s
[2017-12-11 12:46:39] CPU #2: 1087 H, 19.65 H/s
[2017-12-11 12:46:39] CPU #7: 1048 H, 18.94 H/s
[2017-12-11 12:46:39] CPU #0: 1099 H, 19.85 H/s
[2017-12-11 12:46:39] CPU #5: 1673 H, 30.23 H/s
[2017-12-11 12:46:39] CPU #4: 1693 H, 30.58 H/s
[2017-12-11 12:46:39] CPU #9: 1046 H, 18.89 H/s
[2017-12-11 12:46:39] CPU #3: 1088 H, 19.65 H/s
[2017-12-11 12:46:39] CPU #1: 1090 H, 19.68 H/s
[2017-12-11 12:46:40] CPU #6: 905 H, 16.34 H/s
[2017-12-11 12:47:35] Stratum difficulty set to 245006
[2017-12-11 12:47:35] CPU #1: 1097 H, 19.75 H/s
[2017-12-11 12:47:35] CPU #7: 1055 H, 18.98 H/s
[2017-12-11 12:47:35] CPU #0: 1108 H, 19.94 H/s
[2017-12-11 12:47:35] CPU #9: 1054 H, 18.96 H/s
[2017-12-11 12:47:35] CPU #2: 1097 H, 19.73 H/s
[2017-12-11 12:47:35] CPU #4: 1702 H, 30.62 H/s
[2017-12-11 12:47:35] CPU #5: 1685 H, 30.31 H/s
[2017-12-11 12:47:35] CPU #6: 903 H, 16.26 H/s
[2017-12-11 12:47:35] CPU #3: 1097 H, 19.73 H/s
[2017-12-11 12:47:35] CPU #8: 1055 H, 18.97 H/s
[2017-12-11 12:48:31] Stratum difficulty set to 171503
[2017-12-11 12:48:31] CPU #8: 1055 H, 19.01 H/s
[2017-12-11 12:48:31] CPU #0: 1109 H, 19.97 H/s
[2017-12-11 12:48:31] CPU #2: 1097 H, 19.76 H/s
[2017-12-11 12:48:31] CPU #6: 906 H, 16.32 H/s
[2017-12-11 12:48:31] CPU #9: 1056 H, 19.02 H/s
[2017-12-11 12:48:31] CPU #4: 1702 H, 30.65 H/s
[2017-12-11 12:48:31] CPU #5: 1685 H, 30.34 H/s
[2017-12-11 12:48:31] CPU #7: 1057 H, 19.03 H/s
[2017-12-11 12:48:31] CPU #3: 1097 H, 19.75 H/s
[2017-12-11 12:48:31] CPU #1: 1099 H, 19.78 H/s
[2017-12-11 12:48:46] CPU #2: 296 H, 19.58 H/s
[2017-12-11 12:48:46] CPU #9: 284 H, 18.79 H/s
[2017-12-11 12:48:46] CPU #8: 285 H, 18.81 H/s
[2017-12-11 12:48:46] CPU #4: 462 H, 30.52 H/s
[2017-12-11 12:48:46] CPU #5: 457 H, 30.20 H/s
[2017-12-11 12:48:46] CPU #3: 296 H, 19.57 H/s
[2017-12-11 12:48:46] CPU #0: 301 H, 19.84 H/s
[2017-12-11 12:48:46] CPU #1: 297 H, 19.63 H/s
[2017-12-11 12:48:46] CPU #7: 286 H, 18.89 H/s
[2017-12-11 12:48:46] CPU #6: 246 H, 16.22 H/s

When I do a control-c to kill it, watchdog never attempts to restart it.  I also never get email notifications that it quit.

So for now, I'm just running that launch command from the ssh window and things are running smoothly again like on 19-1.4

EDIT:  That launch command is showing -u crazydate.115 -p x where it should be -u crazydane.miner06 -p solar I would think.

mph ignores the password, but is should be passing along the MINER_PWD set in 1bash should it not?

In my case, that would be:

Code:

# For zpool use MINER_PWD="$WORKERNAME,c=btc"
MINER_PWD="solar"               # Set the miner password. Default: x

It just so happens that the ip address I have mapped to miner06 is 10.0.1.115.  So it looks like instead of the host name, it is passing the last part of the ip address.

EDIT2:   I switched to LOCAL and that allows both miners to run.

I get this:

Code:

m1@miner06:~$ ps -ef |grep miner
avahi      905     1  0 13:09 ?        00:00:00 avahi-daemon: running [miner06.local]
m1        2067  2050 99 13:09 pts/20   00:08:16 /home/m1/cpuOPT/cpuminer -a cryptonight -o stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580 -u crazydane.115 -p x -t 10
m1        2295  1241  0 13:09 ?        00:00:00 SCREEN -dmSL miner /home/m1/ASccminer/ccminer -a lyra2v2 -o stratum+tcp://hub.miningpoolhub.com:20507 -u crazydane.115 -p solar -i 21
m1        2296  2295  0 13:09 pts/24   00:00:00 /home/m1/ASccminer/ccminer -a lyra2v2 -o stratum+tcp://hub.miningpoolhub.com:20507 -u crazydane.115 -p solar -i 21
m1        2306  1953  0 13:09 pts/17   00:00:00 screen -r miner

From the above, we have:

-u crazydane.115 -p x
-u crazydane.115 -p solar

And it should be:

-u crazydane.miner06 -p solar
-u crazydane.miner06 -p solar

[papampi]

Does it quits on remote or local or both?

Restart miner and try to catch the command by :

Code:

ps ax | grep -i pluscpu 

or

Code:

ps ax | grep plusCPU

Copy the output and run it with from /home/m1/ .... to the end in guake terminal to catch if miner quits or some thing else kills it

I don't have a local display attached, I run remote only.  I captured the command that executes and when I execute it from a ssh session, the miner works fine.

Code:

m1@miner06:~$ /home/m1/cpuOPT/cpuminer -a cryptonight -o stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580 -u crazydane.115 -p x -t 10

         **********  cpuminer-opt 3.6.3  ***********
     A CPU miner with multi algo support and optimized for CPUs
     with AES_NI and AVX extensions.
     BTC donation address: 12tdvfF7KmAsihBXQXynT6E6th2c2pByTT
     Forked from TPruvot's cpuminer-multi with credits
     to Lucas Jones, elmad, palmd, djm34, pooler, ig0tik3d,
     Wolf0, Jeff Garzik and Optiminer.

CPU: Intel(R) Core(TM) i7-6850K CPU @ 3.60GHz
CPU features: SSE2 AES AVX AVX2
SW built on May 18 2017 with GCC 5.4.0
SW features: SSE2
Algo features: SSE2 AES
Start mining with SSE2

[2017-12-11 12:45:25] Starting Stratum on stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580
[2017-12-11 12:45:25] 10 miner threads started, using 'cryptonight' algorithm.
[2017-12-11 12:45:26] Stratum difficulty set to 500054
[2017-12-11 12:45:29] CPU #4: 66 H, 28.78 H/s
[2017-12-11 12:45:30] CPU #5: 66 H, 28.43 H/s
[2017-12-11 12:45:31] CPU #0: 66 H, 19.10 H/s
[2017-12-11 12:45:31] CPU #1: 66 H, 18.81 H/s
[2017-12-11 12:45:31] CPU #2: 66 H, 18.74 H/s
[2017-12-11 12:45:31] CPU #3: 66 H, 18.53 H/s
[2017-12-11 12:45:31] CPU #7: 66 H, 18.11 H/s
[2017-12-11 12:45:31] CPU #8: 66 H, 17.94 H/s
[2017-12-11 12:45:31] CPU #9: 66 H, 17.73 H/s
[2017-12-11 12:45:31] CPU #6: 66 H, 15.76 H/s
[2017-12-11 12:45:44] CPU #8: 250 H, 18.93 H/s
[2017-12-11 12:45:44] CPU #0: 267 H, 19.87 H/s
[2017-12-11 12:45:44] CPU #3: 262 H, 19.65 H/s
[2017-12-11 12:45:44] CPU #1: 264 H, 19.71 H/s
[2017-12-11 12:45:44] CPU #4: 447 H, 30.59 H/s
[2017-12-11 12:45:44] CPU #9: 250 H, 18.96 H/s
[2017-12-11 12:45:44] CPU #5: 441 H, 30.21 H/s
[2017-12-11 12:45:44] CPU #2: 263 H, 19.62 H/s
[2017-12-11 12:45:44] CPU #6: 208 H, 16.32 H/s
[2017-12-11 12:45:44] CPU #7: 252 H, 18.97 H/s
[2017-12-11 12:46:39] Stratum difficulty set to 350009
[2017-12-11 12:46:39] CPU #8: 1046 H, 18.90 H/s
[2017-12-11 12:46:39] CPU #2: 1087 H, 19.65 H/s
[2017-12-11 12:46:39] CPU #7: 1048 H, 18.94 H/s
[2017-12-11 12:46:39] CPU #0: 1099 H, 19.85 H/s
[2017-12-11 12:46:39] CPU #5: 1673 H, 30.23 H/s
[2017-12-11 12:46:39] CPU #4: 1693 H, 30.58 H/s
[2017-12-11 12:46:39] CPU #9: 1046 H, 18.89 H/s
[2017-12-11 12:46:39] CPU #3: 1088 H, 19.65 H/s
[2017-12-11 12:46:39] CPU #1: 1090 H, 19.68 H/s
[2017-12-11 12:46:40] CPU #6: 905 H, 16.34 H/s
[2017-12-11 12:47:35] Stratum difficulty set to 245006
[2017-12-11 12:47:35] CPU #1: 1097 H, 19.75 H/s
[2017-12-11 12:47:35] CPU #7: 1055 H, 18.98 H/s
[2017-12-11 12:47:35] CPU #0: 1108 H, 19.94 H/s
[2017-12-11 12:47:35] CPU #9: 1054 H, 18.96 H/s
[2017-12-11 12:47:35] CPU #2: 1097 H, 19.73 H/s
[2017-12-11 12:47:35] CPU #4: 1702 H, 30.62 H/s
[2017-12-11 12:47:35] CPU #5: 1685 H, 30.31 H/s
[2017-12-11 12:47:35] CPU #6: 903 H, 16.26 H/s
[2017-12-11 12:47:35] CPU #3: 1097 H, 19.73 H/s
[2017-12-11 12:47:35] CPU #8: 1055 H, 18.97 H/s
[2017-12-11 12:48:31] Stratum difficulty set to 171503
[2017-12-11 12:48:31] CPU #8: 1055 H, 19.01 H/s
[2017-12-11 12:48:31] CPU #0: 1109 H, 19.97 H/s
[2017-12-11 12:48:31] CPU #2: 1097 H, 19.76 H/s
[2017-12-11 12:48:31] CPU #6: 906 H, 16.32 H/s
[2017-12-11 12:48:31] CPU #9: 1056 H, 19.02 H/s
[2017-12-11 12:48:31] CPU #4: 1702 H, 30.65 H/s
[2017-12-11 12:48:31] CPU #5: 1685 H, 30.34 H/s
[2017-12-11 12:48:31] CPU #7: 1057 H, 19.03 H/s
[2017-12-11 12:48:31] CPU #3: 1097 H, 19.75 H/s
[2017-12-11 12:48:31] CPU #1: 1099 H, 19.78 H/s
[2017-12-11 12:48:46] CPU #2: 296 H, 19.58 H/s
[2017-12-11 12:48:46] CPU #9: 284 H, 18.79 H/s
[2017-12-11 12:48:46] CPU #8: 285 H, 18.81 H/s
[2017-12-11 12:48:46] CPU #4: 462 H, 30.52 H/s
[2017-12-11 12:48:46] CPU #5: 457 H, 30.20 H/s
[2017-12-11 12:48:46] CPU #3: 296 H, 19.57 H/s
[2017-12-11 12:48:46] CPU #0: 301 H, 19.84 H/s
[2017-12-11 12:48:46] CPU #1: 297 H, 19.63 H/s
[2017-12-11 12:48:46] CPU #7: 286 H, 18.89 H/s
[2017-12-11 12:48:46] CPU #6: 246 H, 16.22 H/s

When I do a control-c to kill it, watchdog never attempts to restart it.  I also never get email notifications that it quit.

So for now, I'm just running that launch command from the ssh window and things are running smoothly again like on 19-1.4

EDIT:  That launch command is showing -u crazydate.115 where it should be -u crazydane.solar

mph ignores the password, but is should be passing along the MINER_PWD set in 1bash should it not?

In my case, that would be:

Code:

# For zpool use MINER_PWD="$WORKERNAME,c=btc"
MINER_PWD="solar"               # Set the miner password. Default: x

It just so happens that the ip address I have mapped to miner06 is 10.0.1.115.  Coincidence?

OK, another bug in 3main, but I think its irrelevant as mph says it doesnt check the worker password
Password is missing from 3main launch command

Change from :

Code:

      guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT"
    else
      screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT

To :

Code:

     guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
    else
      screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT

There is also some settings in 0miner, open 0miner
in xmr section, change

Code:

"pool_password" : "x",

to

Code:

"pool_password" : "MINER_PWD ",

Also can you post contents of this file after you start miner if it fails:

Code:

/home/m1/xmr/stakGPU/bin/config.txt

[papampi]

When I do a control-c to kill it, watchdog never attempts to restart it.  I also never get email notifications that it quit.

Watchdog has always been only checking GPU

[crazydane]

I just edited my previous reply.  It would appear that host name is not being passed either.  Instead the last octet of the ip address is being used.

[crazydane]

Change from :

Code:

      guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT"
    else
      screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p x -t $threadCOUNT

To :

Code:

     guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
    else
      screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT

There is also some settings in 0miner, open 0miner
in xmr section, change

Code:

"pool_password" : "x",

to

Code:

"pool_password" : "MINER_PWD ",

Made the above changes except I used "MINER_PWD" instead of "MINER_PWD "  and restarted, but I'm still getting:

Code:

/home/m1/cpuOPT/cpuminer -a cryptonight -o stratum+tcp://us-east.cryptonight-hub.miningpoolhub.com:20580 -u crazydane.115 -p x         -t 10

And:

Code:

 /home/m1/ASccminer/ccminer -a lyra2v2 -o stratum+tcp://hub.miningpoolhub.com:20507 -u crazydane.115 -p solar -i 21

So password is being passed for GPU miner, but not CPU miner.

And for both miners, the last octet of the ip addresses is being passed instead of the hostname.

[papampi]

who can share their experience with which more profitable mining best coin in current moment or mining one?

This isn't the right thread for that question man, better luck in other threads, especially those that are covering the GPU you are using as there are many different variables that determine this question

Yes and NO

looks like most people who use WTM is using nvOC, thats why I ask here if any one can share their experience

If by people using wtm you mean wtm auto switch then the answer is simple ...

Add the coins you see they are profitable in wtm web page or coins you like more to wtm section in 1bash :

Code:

WTM_AUTO_SWITCH_COINS="ZEC;ZEN;ETH;BTG;FTC;MONA;VTC;;TZC"

Set WTM_AUTO_SWITCH=YES
and carry on mining ...

[papampi]

I just edited my previous reply.  It would appear that host name is not being passed either.  Instead the last octet of the ip address is being used.

From 1bash:

Code:

AUTO_WORKERNAME="HOST"      # HOST or MAC or CUSTOM # Use HOST IP address or network card MAC address or CUSTOM name workername

[Stubo]

I just edited my previous reply.  It would appear that host name is not being passed either.  Instead the last octet of the ip address is being used.

See if you have these set properly in 1bash:

Code:

AUTO_WORKERNAME="CUSTOM"      # HOST or MAC or CUSTOM # Use HOST IP address or network card MAC address or CUSTOM name workername

CUSTOM_WORKERNAME=$HOSTNAME # If AUTO_WORKERNAME="CUSTOM" enter your desired workername here

I suspect AUTO_WORKERNAME is set to HOST.

[crazydane]

Ah yes.  Sorry guys.  My bad.  I forgot to change those back to CUSTOM and $HOSTNAME after running the update script.

So only outstanding issues that I have now are related to plusCPU;

1. Only works in LOCAL, not REMOTE
2. Password being passed is x and not MINER_PWD

I have:

0miner

Code:

"pool_address" : "$XMR_POOL:$XMR_PORT",
"wallet_address" : "$ADDR",
"pool_password" : "MINER_PWD",

"call_timeout" : 10,
"retry_time" : 10,
"giveup_limit" : 0,

1bash

Code:

# XMR : if plusCPU is "YES" replace with your XMR info  ##
XMR_WORKER=$WORKERNAME
XMR_ADDRESS="crazydane"
XMR_POOL="us-east.cryptonight-hub.miningpoolhub.com"
XMR_PORT="20580"

3main

Code:

if [ $plusCPU == "YES" ] && [ $AUTO_START_MINER == "YES" ]
then
  HCD='/home/m1/cpuOPT/cpuminer'
  XMRADDR="$XMR_ADDRESS.$XMR_WORKER"
  echo ""
  echo ""
  echo "LAUNCHING:  plusCPU"
  if [[ `ps -ef |grep cpuminer |grep -v grep |wc -l` -eq 0 ]]
  then
    if [ $LOCALorREMOTE == "LOCAL" ]
    then
      guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
    else
      screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT
    fi
    echo ""
    echo "plusCPU process in guake terminal Tab (f12)"
    echo ""
    running=""
  fi

[joshuajones02]

I'm having issues with the 19-2 test release and network stability. Not sure quite sure what is going on and it has happened twice so far.

My home router will lose internet connectivity after a period of time (12 hours first time, ~5 hours second time) since updating to the tested release. When I remove the wired connections (clients running 19-2) from my router that goes to the rigs the internet will immediately go back online. Not sure where to check for logs regarding this as the entire router (wifi and wired) loses internet connection.

Version:

Code:

nvOC_1bash_ver="v0019-2.0.001"   # Do not edit this

Is there a way to downgrade the client without imaging the hard drive/usb?

[papampi]

I'm having issues with the 19-2 test release and network stability. Not sure quite sure what is going on and it has happened twice so far.

My home router will lose internet connectivity after a period of time (12 hours first time, ~5 hours second time) since updating to the tested release. When I remove the wired connections (clients running 19-2) from my router that goes to the rigs the internet will immediately go back online. Not sure where to check for logs regarding this as the entire router (wifi and wired) loses internet connection.

Version:

Code:

nvOC_1bash_ver="v0019-2.0.001"   # Do not edit this

Is there a way to downgrade the client without imaging the hard drive/usb?

Your issue can not be update problem as only some scripts changed, but all your old files are stored in /home/m1/backups/old_to19_2

[joshuajones02]

I'm having issues with the 19-2 test release and network stability. Not sure quite sure what is going on and it has happened twice so far.

My home router will lose internet connectivity after a period of time (12 hours first time, ~5 hours second time) since updating to the tested release. When I remove the wired connections (clients running 19-2) from my router that goes to the rigs the internet will immediately go back online. Not sure where to check for logs regarding this as the entire router (wifi and wired) loses internet connection.

Version:

Code:

nvOC_1bash_ver="v0019-2.0.001"   # Do not edit this

Is there a way to downgrade the client without imaging the hard drive/usb?

Your issue can be update problem as only some scripts changed, but all your old files are stored in /home/m1/backups/old_to19_2

Thanks, but did you mean can't? lol. Guess maybe its just coincidental.

[papampi]

I'm having issues with the 19-2 test release and network stability. Not sure quite sure what is going on and it has happened twice so far.

My home router will lose internet connectivity after a period of time (12 hours first time, ~5 hours second time) since updating to the tested release. When I remove the wired connections (clients running 19-2) from my router that goes to the rigs the internet will immediately go back online. Not sure where to check for logs regarding this as the entire router (wifi and wired) loses internet connection.

Version:

Code:

nvOC_1bash_ver="v0019-2.0.001"   # Do not edit this

Is there a way to downgrade the client without imaging the hard drive/usb?

Your issue can be update problem as only some scripts changed, but all your old files are stored in /home/m1/backups/old_to19_2

Thanks, but did you mean can't? lol. Guess maybe its just coincidental.

lol ... yes my typos as always ...

[Stubo]

Ah yes.  Sorry guys.  My bad.  I forgot to change those back to CUSTOM and $HOSTNAME after running the update script.

So only outstanding issues that I have now are related to plusCPU;

1. Only works in LOCAL, not REMOTE
2. Password being passed is x and not MINER_PWD

I have:

0miner

Code:

"pool_address" : "$XMR_POOL:$XMR_PORT",
"wallet_address" : "$ADDR",
"pool_password" : "MINER_PWD",

"call_timeout" : 10,
"retry_time" : 10,
"giveup_limit" : 0,

1bash

Code:

# XMR : if plusCPU is "YES" replace with your XMR info  ##
XMR_WORKER=$WORKERNAME
XMR_ADDRESS="crazydane"
XMR_POOL="us-east.cryptonight-hub.miningpoolhub.com"
XMR_PORT="20580"

3main

Code:

if [ $plusCPU == "YES" ] && [ $AUTO_START_MINER == "YES" ]
then
  HCD='/home/m1/cpuOPT/cpuminer'
  XMRADDR="$XMR_ADDRESS.$XMR_WORKER"
  echo ""
  echo ""
  echo "LAUNCHING:  plusCPU"
  if [[ `ps -ef |grep cpuminer |grep -v grep |wc -l` -eq 0 ]]
  then
    if [ $LOCALorREMOTE == "LOCAL" ]
    then
      guake -n $HCD -r plusCPU -e "$HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT"
    else
      screen -dmS plusCPU $HCD -a cryptonight -o stratum+tcp://$XMR_POOL:$XMR_PORT -u $XMRADDR -p MINER_PWD -t $threadCOUNT
    fi
    echo ""
    echo "plusCPU process in guake terminal Tab (f12)"
    echo ""
    running=""
  fi

Can you try REMOTE again with the watchdog turned off?

Code:

MINER_WATCHDOG="NO"        # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!

This will help determine if the watchdog is somehow killing plusCPU.

[crazydane]

Can you try REMOTE again with the watchdog turned off?

Code:

MINER_WATCHDOG="NO"        # YES or NO # Monitors the rig and automatically corrects the detected problems. Highly recommended to use this!

This will help determine if the watchdog is somehow killing plusCPU.

Switched back to REMOTE and set WATCHDOG = "NO".

Here are the events upon a reboot:

Code:

Last login: Mon Dec 11 14:09:26 2017 from 10.0.1.212
m1@miner06:~$ screen -ls
There is a screen on:
        2044.plusCPU    (12/11/2017 03:12:03 PM)        (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
        2044.plusCPU    (12/11/2017 03:12:03 PM)        (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
        2044.plusCPU    (12/11/2017 03:12:03 PM)        (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
        2076.temp       (12/11/2017 03:12:07 PM)        (Detached)
        2044.plusCPU    (12/11/2017 03:12:03 PM)        (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
        2076.temp       (12/11/2017 03:12:07 PM)        (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There is a screen on:
        2076.temp       (12/11/2017 03:12:06 PM)        (Detached)
1 Socket in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
        2186.miner      (12/11/2017 03:12:09 PM)        (Detached)
        2076.temp       (12/11/2017 03:12:06 PM)        (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
        2186.miner      (12/11/2017 03:12:10 PM)        (Detached)
        2076.temp       (12/11/2017 03:12:07 PM)        (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
        2186.miner      (12/11/2017 03:12:10 PM)        (Detached)
        2076.temp       (12/11/2017 03:12:07 PM)        (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
        2186.miner      (12/11/2017 03:12:10 PM)        (Detached)
        2076.temp       (12/11/2017 03:12:07 PM)        (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$ screen -ls
There are screens on:
        2186.miner      (12/11/2017 03:12:09 PM)        (Detached)
        2076.temp       (12/11/2017 03:12:06 PM)        (Detached)
2 Sockets in /var/run/screen/S-m1.
m1@miner06:~$

So it appears that watchdog is NOT what kills the plusCPU miner.