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

[papampi]

Do you mean add BTG to WTM auto switch ?
If so, you can do it easily.

Add BTG to your 3main in the appropriate location

restart PAPAMPI_WTM and 3main or reboot the rig:

Code:

pkill -f 3main
pkill -f PAPAMPI_WTM
bash /home/m1/PAPAMPI_WTM &

Done.

Everything looks good Expect that BTG profitabuility seems under ETH . I added to my list in WTM_Switch, but i think it's not sure that it is his glory time at the moment.... Wait & See

I think for better results its best to change your hash rates based on your real hash rates in wtm too.
I get much more hash rate from my 1060 and 1070 than the default values of wtm

For 1060 it says 270 sols for equihash but I get 300~310 with dstm, OC 150, mem 600, power 85
For 1070 it says 430  sols for equihash but I get 460~470 with dstm, OC 150, mem 600, power 125


BTG was at top all day with 110~140%, its time for it to rest and go up again

[papampi]

3) I use X Server to check GPU's overlocking. And there is core clocks looks like in MSI Afterburner (1800-1900Mhz for gtx 1070), but memory clocks are too large (8900-9000Mhz, MSI Afterburner displays 4400Mhz for same GPUs). Such big memory clocks is ok for ubuntu? Any other soft for checking Overlocking?

Linux take a different approach on Memory Clock, its double the value of what you use in windows.
Google it and read more about it

If you are on 1.4 you can see your rig error logs in webinfo too
rigip/index.html

[CryptAtomeTrader44]

Do you mean add BTG to WTM auto switch ?
If so, you can do it easily.

Add BTG to your 3main in the appropriate location

restart PAPAMPI_WTM and 3main or reboot the rig:

Code:

pkill -f 3main
pkill -f PAPAMPI_WTM
bash /home/m1/PAPAMPI_WTM &

Done.

Everything looks good Expect that BTG profitabuility seems under ETH . I added to my list in WTM_Switch, but i think it's not sure that it is his glory time at the moment.... Wait & See

I think for better results its best to change your hash rates based on your real hash rates in wtm too.
I get much more hash rate from my 1060 and 1070 than the default values of wtm

For 1060 it says 270 sols for equihash but I get 300~310 with dstm, OC 150, mem 600, power 85
For 1070 it says 430  sols for equihash but I get 460~470 with dstm, OC 150, mem 600, power 125


BTG was at top all day with 110~140%, its time for it to rest and go up again

Yes, i saw that with others than BTG.

but i had'n't seen this varible before !!!!???  :  

Code:

--pass $MINER_PWD 

Code:

 screen -dmSL miner $HCD --eexit 3 --fee $EWBF_PERCENT --pec --server $BTG_POOL --user $BTGADDR --pass $MINER_PWD --port $BTG_PORT  ;

Where did you added this varible ? In 1bash i présume ? But where in 1bash ?

I'ill put a x manually for the moment.

[papampi]

Do you mean add BTG to WTM auto switch ?
If so, you can do it easily.

Add BTG to your 3main in the appropriate location

restart PAPAMPI_WTM and 3main or reboot the rig:

Code:

pkill -f 3main
pkill -f PAPAMPI_WTM
bash /home/m1/PAPAMPI_WTM &

Done.

Everything looks good Expect that BTG profitabuility seems under ETH . I added to my list in WTM_Switch, but i think it's not sure that it is his glory time at the moment.... Wait & See

I think for better results its best to change your hash rates based on your real hash rates in wtm too.
I get much more hash rate from my 1060 and 1070 than the default values of wtm

For 1060 it says 270 sols for equihash but I get 300~310 with dstm, OC 150, mem 600, power 85
For 1070 it says 430  sols for equihash but I get 460~470 with dstm, OC 150, mem 600, power 125


BTG was at top all day with 110~140%, its time for it to rest and go up again

Yes, i saw that with others than BTG.

but i had'n't seen this varible before !!!!???  :  

Code:

--pass $MINER_PWD 

Code:

 screen -dmSL miner $HCD --eexit 3 --fee $EWBF_PERCENT --pec --server $BTG_POOL --user $BTGADDR --pass $MINER_PWD --port $BTG_PORT  ;

Where did you added this varible ? In 1bash i présume ? But where in 1bash ?

I'ill put a x manually for the moment.

Thats an edit/suggestion by Stubo for next update
You can either add the statement to your 1bash or remove it from the miner start line

Code:

# Set the miner password
MINER_PWD="x"

[Stubo]

Bug in IAmNotAJeep_and_Maxximus007_WATCHDOG?

I was reading over this script in attempt to answer some questions from a fellow nvOC user and ran across what I believe is a bug at the end. I reviewed the original versions include in both 19-1.3 and 19-1.4 and see this code at the end:

Code:

<cut>
else
#IAmNotAJeep MOD from V002
  COUNT=$((6 * $GPU_COUNT))
  echo "$(date) - 5 by 5: REMEMBER TO THANK IAmNotAJeep and Maxximus007"
#IAmNotAJeep MOD from V002
fi

  # No need for a reboot after a while
  if [ $REBOOTRESET -gt 5 ]
  then
    RESTART=0
    REBOOTRESET=0
    #reinit=6
  fi
done

I believe that the last if block should be within the if block that comes just before it since I think the idea behind the logic is to reset the RESTART counter if we make through the while loop 5 times without detecting any GPU's below the utilization THRESHOLD. As written, RESTART is reset to 0 every 5th time through the loop regardless, so the code should be:

Code:

   else
      # All is good, reset the counter
      COUNT=$((6 * $GPU_COUNT))
      echo "$(date) - 5 by 5: REMEMBER TO THANK IAmNotAJeep and Maxximus007"

      # No need for a reboot after 5 times through the main loop with no issues
      if [ $REBOOTRESET -gt 5 ]
      then
         RESTART=0
         REBOOTRESET=0
      fi
   fi
done

Am I misunderstanding the intent here?

[bwillyb]

Why my rig stops after 15 hours ?
I have 4X geeforce windforce gtx 1070

Temp: GPU0: 70C GPU1: 67C GPU2: 59C GPU3: 69C
GPU0: 443 Sol/s GPU1: 445 Sol/s GPU2: 453 Sol/s GPU3: 445 Sol/s
Total speed: 1786 Sol/s
+-----+-------------+--------------+
| GPU | Power usage |  Efficiency  |
+-----+-------------+--------------+
|  0  |    129W     |  3.43 Sol/W  |
|  1  |    135W     |  3.30 Sol/W  |
|  2  |    134W     |  3.38 Sol/W  |
|  3  |    133W     |  3.35 Sol/W  |
+-----+-------------+--------------+

I have a corsair 1200W
MB: ASUS PRIME Z270-A
now power wall is only 615W

power limit at 140W each one
__CORE_OVERCLOCK_1=150
MEMORY_OVERCLOCK_1=580

[papampi]

Bug in IAmNotAJeep_and_Maxximus007_WATCHDOG?

I was reading over this script in attempt to answer some questions from a fellow nvOC user and ran across what I believe is a bug at the end. I reviewed the original versions include in both 19-1.3 and 19-1.4 and see this code at the end:

Code:

<cut>
else
#IAmNotAJeep MOD from V002
  COUNT=$((6 * $GPU_COUNT))
  echo "$(date) - 5 by 5: REMEMBER TO THANK IAmNotAJeep and Maxximus007"
#IAmNotAJeep MOD from V002
fi

  # No need for a reboot after a while
  if [ $REBOOTRESET -gt 5 ]
  then
    RESTART=0
    REBOOTRESET=0
    #reinit=6
  fi
done

I believe that the last if block should be within the if block that comes just before it since I think the idea behind the logic is to reset the RESTART counter if we make through the while loop 5 times without detecting any GPU's below the utilization THRESHOLD. As written, RESTART is reset to 0 every 5th time through the loop regardless, so the code should be:

Code:

   else
      # All is good, reset the counter
      COUNT=$((6 * $GPU_COUNT))
      echo "$(date) - 5 by 5: REMEMBER TO THANK IAmNotAJeep and Maxximus007"

      # No need for a reboot after 5 times through the main loop with no issues
      if [ $REBOOTRESET -gt 5 ]
      then
         RESTART=0
         REBOOTRESET=0
      fi
   fi
done

Am I misunderstanding the intent here?

I tested both scenarios with a small change in your Debug code
Used ewbf and set threshold to 100 to see what happenes

added this at the end before done

Code:

    echo "Debug: JEEP=$JEEP, COUNT=$COUNT, RESTART=$RESTART REBOOTRESET=$REBOOTRESET"

With the original code, wdog resets REBOOTRESET after 5 cycles, with your proposal REBOOTRESET keeps adding up, and wont resets after 5.
So my conclusion is the original code should be correct. 

[papampi]

Why my rig stops after 15 hours ?
I have 4X geeforce windforce gtx 1070

Temp: GPU0: 70C GPU1: 67C GPU2: 59C GPU3: 69C
GPU0: 443 Sol/s GPU1: 445 Sol/s GPU2: 453 Sol/s GPU3: 445 Sol/s
Total speed: 1786 Sol/s
+-----+-------------+--------------+
| GPU | Power usage |  Efficiency  |
+-----+-------------+--------------+
|  0  |    129W     |  3.43 Sol/W  |
|  1  |    135W     |  3.30 Sol/W  |
|  2  |    134W     |  3.38 Sol/W  |
|  3  |    133W     |  3.35 Sol/W  |
+-----+-------------+--------------+

I have a corsair 1200W
MB: ASUS PRIME Z270-A
now power wall is only 615W

power limit at 140W each one
__CORE_OVERCLOCK_1=150
MEMORY_OVERCLOCK_1=580

Not enough info
Check your wdog logs, may be utilization dropped, internet had a hiccup, or .... 

[CyberGI]

GPU Card Specific settings question:

Y'all - I'm running 19-1.4 with three Zotec 1070 Minis. It spends a lot of time between ETH and FTC. I tried turning up the damNmad Algo-specific OC settings (stock in 1bash) and my ETH hashrate went from 82M to 66M. Is there a resource someone could point me to for recommended settings for these card?

Thanks,

Joe

[bwillyb]

Why my rig stops after 15 hours ?
I have 4X geeforce windforce gtx 1070

Temp: GPU0: 70C GPU1: 67C GPU2: 59C GPU3: 69C
GPU0: 443 Sol/s GPU1: 445 Sol/s GPU2: 453 Sol/s GPU3: 445 Sol/s
Total speed: 1786 Sol/s
+-----+-------------+--------------+
| GPU | Power usage |  Efficiency  |
+-----+-------------+--------------+
|  0  |    129W     |  3.43 Sol/W  |
|  1  |    135W     |  3.30 Sol/W  |
|  2  |    134W     |  3.38 Sol/W  |
|  3  |    133W     |  3.35 Sol/W  |
+-----+-------------+--------------+

I have a corsair 1200W
MB: ASUS PRIME Z270-A
now power wall is only 615W

power limit at 140W each one
__CORE_OVERCLOCK_1=150
MEMORY_OVERCLOCK_1=580

Not enough info
Check your wdog logs, may be utilization dropped, internet had a hiccup, or ....  

Mon Nov 27 00:30:56 CET 2017 - reboot in 10 seconds
Mon Nov 27 00:46:48 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 01:32:44 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 04:47:39 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 05:03:25 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 05:40:57 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 05:55:32 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 06:54:42 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 08:31:25 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 10:01:26 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 11:03:27 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 13:13:01 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 13:52:24 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:01:38 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:01:48 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:01:58 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:02:08 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:02:18 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:02:28 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:03:41 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:04:53 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:06:05 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:07:20 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:08:32 CET 2017 - Utilization is too low: reviving did not work so restarting system in 10 seconds
Mon Nov 27 16:57:48 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 17:11:23 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 17:45:45 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 18:14:25 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 18:17:36 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures

[CyberGI]

how check wdog logs?

In the bash shell, more/less/cat/tail (whichever is your favorite) 7_wdog_alertlog

Code:

~$ less 7_wdog_alertlog

HTH

[Stubo]

I tested both scenarios with a small change in your Debug code
Used ewbf and set threshold to 100 to see what happenes

added this at the end before done

Code:

    echo "Debug: JEEP=$JEEP, COUNT=$COUNT, RESTART=$RESTART REBOOTRESET=$REBOOTRESET"

With the original code, wdog resets REBOOTRESET after 5 cycles, with your proposal REBOOTRESET keeps adding up, and wont resets after 5.
So my conclusion is the original code should be correct.  

With the THRESHOLD set to 100, you would almost always have a utilization error so the miner would be restarting and eventually the host. This code is not intended for that situation. In fact, your test proves just the opposite of your conclusion. The REBOOTRESET should continue to increase until such a point as the watchdog detects normal mining operations at which point it will hit the else part part of the if (JEEP=0) and will find that REBOOTRESET is greater than 5 and will then set both REBOOTRESET and RESTART to 0.

[Stubo]

Why my rig stops after 15 hours ?
I have 4X geeforce windforce gtx 1070

Temp: GPU0: 70C GPU1: 67C GPU2: 59C GPU3: 69C
GPU0: 443 Sol/s GPU1: 445 Sol/s GPU2: 453 Sol/s GPU3: 445 Sol/s
Total speed: 1786 Sol/s
+-----+-------------+--------------+
| GPU | Power usage |  Efficiency  |
+-----+-------------+--------------+
|  0  |    129W     |  3.43 Sol/W  |
|  1  |    135W     |  3.30 Sol/W  |
|  2  |    134W     |  3.38 Sol/W  |
|  3  |    133W     |  3.35 Sol/W  |
+-----+-------------+--------------+

I have a corsair 1200W
MB: ASUS PRIME Z270-A
now power wall is only 615W

power limit at 140W each one
__CORE_OVERCLOCK_1=150
MEMORY_OVERCLOCK_1=580

Not enough info
Check your wdog logs, may be utilization dropped, internet had a hiccup, or ....  

Mon Nov 27 00:30:56 CET 2017 - reboot in 10 seconds
Mon Nov 27 00:46:48 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 01:32:44 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 04:47:39 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 05:03:25 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 05:40:57 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 05:55:32 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 06:54:42 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 08:31:25 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 10:01:26 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 11:03:27 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 13:13:01 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 13:52:24 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:01:38 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:01:48 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:01:58 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:02:08 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:02:18 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 15:02:28 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:03:41 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:04:53 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:06:05 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:07:20 CET 2017 - Utilization is too low: restart 3main
Mon Nov 27 15:08:32 CET 2017 - Utilization is too low: reviving did not work so restarting system in 10 seconds
Mon Nov 27 16:57:48 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 17:11:23 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 17:45:45 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 18:14:25 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures
Mon Nov 27 18:17:36 CET 2017 - Low Utilization Detected: 3main will reinit if there are 6 consecutive failures

Ok, we see from that that the watchdog is detecting low utilization and restarting the miner and after 5 miner restarts, reboots the host. That is the normal behavior of the watchdog script. Now we have to find out why the miner is not mining. Can you check /home/m1/screenlog.0 for errors from the miner?

[bwillyb]

screenlog seems to be till 20 november

[bwillyb]

ok Found
Total speed: 1811 Sol/s
INFO 15:01:17: GPU0 Accepted share 35ms [A:993, R:0]
INFO: Detected new work: d2d1
ERROR: Lost connection with the server.
INFO: Attempt to restore connection.
ERROR: Cannot connect to the pool
ERROR: Lost connection with the server.
INFO: Attempt to restore connection.
ERROR: Cannot connect to the pool
ERROR: Lost connection with the server.
INFO: Attempt to restore connection.
ERROR: Stratum subscribe timeout
INFO: Target: 0003333333333333...
INFO: Detected new work: cce3
CUDA: Device: 0 GeForce GTX 1070, 8112 MB PCI: 0000:01:00.0
CUDA: Device: 1 GeForce GTX 1070, 8113 MB PCI: 0000:03:00.0
CUDA: Device: 2 GeForce GTX 1070, 8113 MB PCI: 0000:04:00.0
CUDA: Device: 3 GeForce GTX 1070, 8113 MB PCI: 0000:05:00.0
CUDA: Device: 1 Selected solver: 0
CUDA: Device: 0 Selected solver: 0
CUDA: Device: 2 Selected solver: 0
CUDA: Device: 3 Selected solver: 0
INFO: Detected new work: cce4
INFO 15:16:20: GPU3 Accepted share 37ms [A:1, R:0]
INFO 15:16:26: GPU3 Accepted share 37ms [A:2, R:0]
Temp: GPU0 53C GPU1 51C GPU2 49C GPU3 51C
GPU0: 457 Sol/s GPU1: 456 Sol/s GPU2: 464 Sol/s GPU3: 454 Sol/s
Total speed: 1831 Sol/s

[papampi]

I tested both scenarios with a small change in your Debug code
Used ewbf and set threshold to 100 to see what happenes

added this at the end before done

Code:

    echo "Debug: JEEP=$JEEP, COUNT=$COUNT, RESTART=$RESTART REBOOTRESET=$REBOOTRESET"

With the original code, wdog resets REBOOTRESET after 5 cycles, with your proposal REBOOTRESET keeps adding up, and wont resets after 5.
So my conclusion is the original code should be correct.  

With the THRESHOLD set to 100, you would almost always have a utilization error so the miner would be restarting and eventually the host. This code is not intended for that situation. In fact, your test proves just the opposite of your conclusion. The REBOOTRESET should continue to increase until such a point as the watchdog detects normal mining operations at which point it will hit the else part part of the if (JEEP=0) and will find that REBOOTRESET is greater than 5 and will then set both REBOOTRESET and RESTART to 0.

REBOOTRESET increases by every cycle (10 seconds), no matter if there is a low util, no miner, ...
Take a look at the code you see its on top, before checking utilization

Edit:
I have only 2 cards on my test rig, so I set threshold to 100 to see whats happening when there is low utilization

But when I read your logic again, that should be it, not the way it is now
will test more later

[Stubo]

ok Found
Total speed: 1811 Sol/s
INFO 15:01:17: GPU0 Accepted share 35ms [A:993, R:0]
INFO: Detected new work: d2d1
ERROR: Lost connection with the server.
INFO: Attempt to restore connection.
ERROR: Cannot connect to the pool
ERROR: Lost connection with the server.
INFO: Attempt to restore connection.
ERROR: Cannot connect to the pool
ERROR: Lost connection with the server.
INFO: Attempt to restore connection.
ERROR: Stratum subscribe timeout
INFO: Target: 0003333333333333...
INFO: Detected new work: cce3
CUDA: Device: 0 GeForce GTX 1070, 8112 MB PCI: 0000:01:00.0
CUDA: Device: 1 GeForce GTX 1070, 8113 MB PCI: 0000:03:00.0
CUDA: Device: 2 GeForce GTX 1070, 8113 MB PCI: 0000:04:00.0
CUDA: Device: 3 GeForce GTX 1070, 8113 MB PCI: 0000:05:00.0
CUDA: Device: 1 Selected solver: 0
CUDA: Device: 0 Selected solver: 0
CUDA: Device: 2 Selected solver: 0
CUDA: Device: 3 Selected solver: 0
INFO: Detected new work: cce4
INFO 15:16:20: GPU3 Accepted share 37ms [A:1, R:0]
INFO 15:16:26: GPU3 Accepted share 37ms [A:2, R:0]
Temp: GPU0 53C GPU1 51C GPU2 49C GPU3 51C
GPU0: 457 Sol/s GPU1: 456 Sol/s GPU2: 464 Sol/s GPU3: 454 Sol/s
Total speed: 1831 Sol/s

Well, that appears to be the answer to your original question. Your rig stopped mining after 15 hours because the miner lost connectivity to the pool. Either your rig lost connectivity or the pool was down.

[Stubo]

I tested both scenarios with a small change in your Debug code
Used ewbf and set threshold to 100 to see what happenes

added this at the end before done

Code:

    echo "Debug: JEEP=$JEEP, COUNT=$COUNT, RESTART=$RESTART REBOOTRESET=$REBOOTRESET"

With the original code, wdog resets REBOOTRESET after 5 cycles, with your proposal REBOOTRESET keeps adding up, and wont resets after 5.
So my conclusion is the original code should be correct.  

With the THRESHOLD set to 100, you would almost always have a utilization error so the miner would be restarting and eventually the host. This code is not intended for that situation. In fact, your test proves just the opposite of your conclusion. The REBOOTRESET should continue to increase until such a point as the watchdog detects normal mining operations at which point it will hit the else part part of the if (JEEP=0) and will find that REBOOTRESET is greater than 5 and will then set both REBOOTRESET and RESTART to 0.

REBOOTRESET increases by every cycle (10 seconds), no matter if there is a low util, no miner, ...
Take a look at the code you see its on top, before checking utilization

Edit:
I have only 2 cards on my test rig, so I set threshold to 100 to see whats happening when there is low utilization

But when I read your logic again, that should be it, not the way it is now
will test more later

Yeah, when looking at the code, check the other places where REBOOTRESET is changed. Note it is just after 3main is killed:

Code:

<cut>
         echo ""
         RESTART=$(($RESTART + 1))
         REBOOTRESET=0
         COUNT=$GPU_COUNT
<cut>

So, I think the intent of developer was to find a way to reset variable RESTART to 0 to avoid unnecessary host reboots and the best way to do that is only if you can make it through the main loop without any "below utilization" problems.

Also, another minor bug is that REBOOTRESET is never initialized at the beginning of the script. The first reference to it is when it is incremented by 1 within the main [while] loop. I am not sure why that doesn't throw an error.

[bwillyb]

ok Found
Total speed: 1811 Sol/s
INFO 15:01:17: GPU0 Accepted share 35ms [A:993, R:0]
INFO: Detected new work: d2d1
ERROR: Lost connection with the server.
INFO: Attempt to restore connection.
ERROR: Cannot connect to the pool
ERROR: Lost connection with the server.
INFO: Attempt to restore connection.
ERROR: Cannot connect to the pool
ERROR: Lost connection with the server.
INFO: Attempt to restore connection.
ERROR: Stratum subscribe timeout
INFO: Target: 0003333333333333...
INFO: Detected new work: cce3
CUDA: Device: 0 GeForce GTX 1070, 8112 MB PCI: 0000:01:00.0
CUDA: Device: 1 GeForce GTX 1070, 8113 MB PCI: 0000:03:00.0
CUDA: Device: 2 GeForce GTX 1070, 8113 MB PCI: 0000:04:00.0
CUDA: Device: 3 GeForce GTX 1070, 8113 MB PCI: 0000:05:00.0
CUDA: Device: 1 Selected solver: 0
CUDA: Device: 0 Selected solver: 0
CUDA: Device: 2 Selected solver: 0
CUDA: Device: 3 Selected solver: 0
INFO: Detected new work: cce4
INFO 15:16:20: GPU3 Accepted share 37ms [A:1, R:0]
INFO 15:16:26: GPU3 Accepted share 37ms [A:2, R:0]
Temp: GPU0 53C GPU1 51C GPU2 49C GPU3 51C
GPU0: 457 Sol/s GPU1: 456 Sol/s GPU2: 464 Sol/s GPU3: 454 Sol/s
Total speed: 1831 Sol/s

Well, that appears to be the answer to your original question. Your rig stopped mining after 15 hours because the miner lost connectivity to the pool. Either your rig lost connectivity or the pool was down.

Sure zcash.pro was down at 15:00
Thanks

[TheNewEthlite]

Hello,

got a problem with rig stop mining, doesn't autoreboot, screen is all green with warning box with nondescript characters. Hard reboot required, attached error screen on reboot.
https://imgur.com/a/QL5K8

Asus H270-plus
6x 1080ti
intel G3930

Any help would be much appreciated.