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

[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

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.

So I tested more and I think the original works better, why?
With your suggestion REBOOTRESET keeps going up, and when 1 no problem occurs it will reset it to 0
But with original code REBOOTRESET resets every 5 cycles, so after failures wdog should check 5 cycles again until it resets the REBOOTRESET again

Edit 1:
Also it resets after 3main restart, so it will start from 0 after 3main restart, So your suggestion should works too.
I think it has potential to do better, we should work on it.
Problem is it adds to it whether there is low util or not, I think it should only get   REBOOTRESET=$(($REBOOTRESET + 1)) if there was no problems at all.


Edit 2:
Suggestion :

add

Code:

  REBOOTRESET=$(($REBOOTRESET - 1))

in this section:

Code:

    # If utilization is lower than threshold count them:

[1714499432]

1714499432

[1714499432]

1714499432

[1714499432]

1714499432

[1714499432]

1714499432

[1714499432]

1714499432

[1714499432]

1714499432

[Stubo]

So I tested more and I think the original works better, why?
With your suggestion REBOOTRESET keeps going up, and when 1 no problem occurs it will reset it to 0
But with original code REBOOTRESET resets every 5 cycles, so after failures wdog should check 5 cycles again until it resets the REBOOTRESET again

Edit 1:
Also it resets after 3main restart, so it will start from 0 after 3main restart, So your suggestion should works too.
I think it has potential to do better, we should work on it.
Problem is it adds to it whether there is low util or not, I think it should only get   REBOOTRESET=$(($REBOOTRESET + 1)) if there was no problems at all.


Edit 2:
Suggestion :

add

Code:

  REBOOTRESET=$(($REBOOTRESET - 1))

in this section:

Code:

    # If utilization is lower than threshold count them:

I think you are getting closer to understanding the code but are still not there. Merely decrementing the counter is a bad idea because it is incremented every time through the main loop so this approach would only lead to it staying the same. Keep in mind that the important part of what REBOOTRESET does is determine when to reset variable RESTART. RESTART is what determines if we do another miner restart or a whole host restart. So really the question becomes, should RESTART be reset to 0 after just 5 times through the main loop regardless of what happens with utilization?

[papampi]

Edit 2:
Suggestion :

add

Code:

  REBOOTRESET=$(($REBOOTRESET - 1))

in this section:

Code:

    # If utilization is lower than threshold count them:

So really the question becomes, should RESTART be reset to 0 after just 5 times through the main loop regardless of what happens with utilization?

Thats exactly why I added the suggestiion in edit 2.
The decrementing happens only if there were low utilization detected so if all is good it will be incremented by each cycle...

[Stubo]

Edit 2:
Suggestion :

add

Code:

  REBOOTRESET=$(($REBOOTRESET - 1))

in this section:

Code:

    # If utilization is lower than threshold count them:

So really the question becomes, should RESTART be reset to 0 after just 5 times through the main loop regardless of what happens with utilization?

Thats exactly why I added the suggestiion in edit 2.
The decrementing happens only if there were low utilization detected so if all is good it will be incremented by each cycle...

I already wrote "Merely decrementing the counter is a bad idea because it is incremented every time through the main loop so this approach would only lead to it staying the same." ...and if it stays the same, RESTART will never get reset to 0, thus breaking the script.

[papampi]

Edit 2:
Suggestion :

add

Code:

  REBOOTRESET=$(($REBOOTRESET - 1))

in this section:

Code:

    # If utilization is lower than threshold count them:

So really the question becomes, should RESTART be reset to 0 after just 5 times through the main loop regardless of what happens with utilization?

Thats exactly why I added the suggestiion in edit 2.
The decrementing happens only if there were low utilization detected so if all is good it will be incremented by each cycle...

I already wrote "Merely decrementing the counter is a bad idea because it is incremented every time through the main loop so this approach would only lead to it staying the same." ...and if it stays the same, RESTART will never get reset to 0, thus breaking the script.

So whats your suggestion
Add an statement for it  after checking utilization?

 

Code:

   if [ $UTIL -gt $THRESHOLD ]
    then
  REBOOTRESET=$(($REBOOTRESET + 1))
fi

[fayaz001]

So i have used the new nvoc 14, and its great

I have a Zotec Geforce GTX 1070 amp card.... and i want to know

   1. how do i switch the led lights off?
   2. How can i overclock the card in Ubuntu?

   many thanks for your help in advance

Fayaz

[papampi]

So i have used the new nvoc 14, and its great

I have a Zotec Geforce GTX 1070 amp card.... and i want to know

   1. how do i switch the led lights off?
   2. How can i overclock the card in Ubuntu?

   many thanks for your help in advance

Fayaz

Dont know about the lghts but overclock settings are in 1bash

Code:

POWERLIMIT_WATTS=125

__CORE_OVERCLOCK=150
MEMORY_OVERCLOCK=600

Those values what I use for equihash mining with gigabyte 1070

[Stubo]

Edit 2:
Suggestion :

add

Code:

  REBOOTRESET=$(($REBOOTRESET - 1))

in this section:

Code:

    # If utilization is lower than threshold count them:

So really the question becomes, should RESTART be reset to 0 after just 5 times through the main loop regardless of what happens with utilization?

Thats exactly why I added the suggestiion in edit 2.
The decrementing happens only if there were low utilization detected so if all is good it will be incremented by each cycle...

I already wrote "Merely decrementing the counter is a bad idea because it is incremented every time through the main loop so this approach would only lead to it staying the same." ...and if it stays the same, RESTART will never get reset to 0, thus breaking the script.

So whats your suggestion
Add an statement for it  after checking utilization?

 

Code:

   if [ $UTIL -gt $THRESHOLD ]
    then
  REBOOTRESET=$(($REBOOTRESET + 1))
fi

My suggestion is what I originally stated.

I admit it is confusing so here is another way of looking at. As written, the script will reset REBOOTRESET to 0 and reset RESTART to 0 every 6th time through the loop unless the miner is restarted (kill 3main) in which case only REBOOTRESET is set back to 0. My proposed change is to only reset both variables on the 6th time through the loop if there were no utilization issues found [which is what moving it "up" into the else clause does]. The REBOOTRESET=0 as a part of miner restart should remain unchanged. As written, the potential is there for RESTART to be reset to 0 even if there are still utilization issues thereby delaying potential host restart. In a nutshell, your rig could limp along longer than necessary with a GPU or 2 down over and over with miner restarts when only a host reboot will fix the problem.

[bennycoinz]

Hey guys I'm pretty new at this. I imaged a USB arrive with v 19 and now it just keeps "cycling" and never starts mining. I set my coin to ubq, made up a worker name and set my wallet and mining pool. All it does is keep loading some I'm not a Jeep and something else over and over! I'm losing hair over this 😀😀

[CyberGI]

I cannot get my hashes for a gtx 1070 to get past 26ish mining eth no matter what I do.

Running nvOC 19 1.4

Is 26 just what linux can do or do I need to keep trying to solve this issue and get higher hashes?

What are your settings? I get 29 MH ETH and 280 MH DCR with PL 125 Core -50 and M 900 from Zotac 1070 mini.

I'm getting 28.8 on the minis. I was getting 26 with the stock settings. I posted earlier today looking for some better settings. I just started messing with it and ended with PL=125, Core=150, and MEM at 600 on the Mini. I'm running three of them.

Anyone else have recommended settings for a 1070, preferably a mini? And thanks for posting y'all's.

Edit: I am now using your 125/-50/900 values and now each of my three cards are cranking out 30Mh/s of ETH. Thanks for the numbers.

With gigabyte 1070 I get
Ethahsh : 30-31 MH/s,  Power 130, CC -200, MC 800
Equihash: 470 Sol/s, Power 125, CC 150, MC 600

Have a look here too : https://bitcointalk.org/index.php?topic=2176936

Awesome! And thanks for the link.

[papampi]

Hey guys I'm pretty new at this. I imaged a USB arrive with v 19 and now it just keeps "cycling" and never starts mining. I set my coin to ubq, made up a worker name and set my wallet and mining pool. All it does is keep loading some I'm not a Jeep and something else over and over! I'm losing hair over this 😀😀

Please post your ubq setting from 1bash

[HiP1]

Hello,
i added a 3rd 1080 Ti GPU in my rig. (H110 Pro BTC+)
but it stopped booting from the USB stick i use. i just hangs after the bios with the "B4" code written in the bottom right of the screen.
does it mean i have to switch to a HDD or SSD  for it to work now ? or do i need more than 4 GB of RAM ?

[papampi]

There are moments that only 1 GPU wont get fully utilize and keep on going like that, problem with the current wdog on multiple GPUs is that it takes so long for wdog to restart 3 main if only one gpu fails, so on a 12 card rig it takes 72 times and while it checks every 10 seconds it will take more than 10 minutes for it to restart 3main

Any idea how to correct this?

[papampi]

Edit 2:
Suggestion :

add

Code:

  REBOOTRESET=$(($REBOOTRESET - 1))

in this section:

Code:

    # If utilization is lower than threshold count them:

So really the question becomes, should RESTART be reset to 0 after just 5 times through the main loop regardless of what happens with utilization?

Thats exactly why I added the suggestiion in edit 2.
The decrementing happens only if there were low utilization detected so if all is good it will be incremented by each cycle...

I already wrote "Merely decrementing the counter is a bad idea because it is incremented every time through the main loop so this approach would only lead to it staying the same." ...and if it stays the same, RESTART will never get reset to 0, thus breaking the script.

So whats your suggestion
Add an statement for it  after checking utilization?

 

Code:

   if [ $UTIL -gt $THRESHOLD ]
    then
  REBOOTRESET=$(($REBOOTRESET + 1))
fi

My suggestion is what I originally stated.

I admit it is confusing so here is another way of looking at. As written, the script will reset REBOOTRESET to 0 and reset RESTART to 0 every 6th time through the loop unless the miner is restarted (kill 3main) in which case only REBOOTRESET is set back to 0. My proposed change is to only reset both variables on the 6th time through the loop if there were no utilization issues found [which is what moving it "up" into the else clause does]. The REBOOTRESET=0 as a part of miner restart should remain unchanged. As written, the potential is there for RESTART to be reset to 0 even if there are still utilization issues thereby delaying potential host restart. In a nutshell, your rig could limp along longer than necessary with a GPU or 2 down over and over with miner restarts when only a host reboot will fix the problem.

Great suggestion and workaround as always... Thanks mate.

[Stubo]

There are moments that only 1 GPU wont get fully utilize and keep on going like that, problem with the current wdog on multiple GPUs is that it takes so long for wdog to restart 3 main if only one gpu fails, so on a 12 card rig it takes 72 times and while it checks every 10 seconds it will take more than 10 minutes for it to restart 3main

Any idea how to correct this?

Oh believe me, I have thought about this one, too, and have yet to arrive and what I feel is a good solution. Having the reboot time grow proportionally to #GPU is not ideal, IMO. I am all ears if somebody wants to chime in. The best that I can come up with is an upper limit on count instead of just 6xGPU. There has to be a better way.

[moofone]

Hi Guys,

I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.

We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.

For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.

We need to apply overclocking to BUS ID:
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1070    Off  | 00000000:02:00.0 Off |                  N/A |
| 70%   56C    P2   152W / 151W |    652MiB /  8112MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 70%   61C    P2   120W / 120W |    592MiB /  6072MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   2  GeForce GTX 1070    Off  | 00000000:05:00.0 Off |                  N/A |
| 70%   52C    P2   118W / 120W |    614MiB /  8113MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+

[Bibi187]

Hi Guys,

I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.

We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.

For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.

We need to apply overclocking to BUS ID:
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1070    Off  | 00000000:02:00.0 Off |                  N/A |
| 70%   56C    P2   152W / 151W |    652MiB /  8112MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 70%   61C    P2   120W / 120W |    592MiB /  6072MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   2  GeForce GTX 1070    Off  | 00000000:05:00.0 Off |                  N/A |
| 70%   52C    P2   118W / 120W |    614MiB /  8113MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+

Nothing to fix at all oO ...

You modified your RIG, you have to modify setting ...

[moofone]

Completely disagree. This is dangerous way to overclock and could lead to catastrophic failure of your rig if a card dies on its own.. and they do.

Its discussed on the nvidia dev form with some python code that could be adopted to nvOC if anyone is interested:

https://devtalk.nvidia.com/default/topic/769851/multi-nvidia-gpus-and-xorg-conf-how-to-account-for-pci-bus-busid-change-/

Hi Guys,

I discovered a serious and potentially dangerous flaw in the way nvOC handles overclocking and would like to make a suggestion for an improvement.

We really need overclocking tied to the specific pcie slot (bus id) not an index that changes every time your hardware changes.

For example, if you have a gtx1080ti in slot 2, and a gtx1060 in slot 3, and your 1080ti goes offline for some reason or you remove it, the 1080ti overclock is now applied to what it thinks is the next card in the dumb index, and applies it to your gtx1060 potentially going POOF.

We need to apply overclocking to BUS ID:
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce GTX 1070    Off  | 00000000:02:00.0 Off |                  N/A |
| 70%   56C    P2   152W / 151W |    652MiB /  8112MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   1  GeForce GTX 106...  Off  | 00000000:04:00.0 Off |                  N/A |
| 70%   61C    P2   120W / 120W |    592MiB /  6072MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+
|   2  GeForce GTX 1070    Off  | 00000000:05:00.0 Off |                  N/A |
| 70%   52C    P2   118W / 120W |    614MiB /  8113MiB |     99%      Default |
+-------------------------------+----------------------+----------------------+

Nothing to fix at all oO ...

You modified your RIG, you have to modify setting ...

[papampi]

There are moments that only 1 GPU wont get fully utilize and keep on going like that, problem with the current wdog on multiple GPUs is that it takes so long for wdog to restart 3 main if only one gpu fails, so on a 12 card rig it takes 72 times and while it checks every 10 seconds it will take more than 10 minutes for it to restart 3main

Any idea how to correct this?

Oh believe me, I have thought about this one, too, and have yet to arrive and what I feel is a good solution. Having the reboot time grow proportionally to #GPU is not ideal, IMO. I am all ears if somebody wants to chime in. The best that I can come up with is an upper limit on count instead of just 6xGPU. There has to be a better way.

I'm sure you have thought about this long before it catch my attention, you have done awesome fix and edits to wdog.
I think the upper limit can cause too fast restart if all gpus fail
There should be a way with bash to catch and compare values by their location in the series, but I'm not sure how.

[TPLivin]

Just wanted to say thank you to fullzero and the team! Just built my 1st rig gtx 1060 x3 mining Ubiq y’all really have a great product Thanks!