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

[fullzero]

Hi,

Please help!
I have got stuck on this problems  
My configuration:

-ASUS PRIME Z270-P - 2 . I tried both, results are similar.
-EVGA GeForce GTX 1080 GAMING ACX 3.0 - 2
-MSI Geforce GTX 1080 Gaming X-  2
-The Gigabyte power supply unit on 1200 watts


Three video cards work perfectly in any any combinations,

m1@m1-desktop:~$ nvidia-smi -L
GPU 0: GeForce GTX 1080 (UUID: GPU-43453088-0fca-9442-106d-7594d157ebf2)
GPU 1: GeForce GTX 1080 (UUID: GPU-d099b67e-f204-66fa-96dc-365a6b559a7e)
GPU 2: GeForce GTX 1080 (UUID: GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac)
m1@m1-desktop:~$

m1@m1-desktop:~$ lspci |grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
03:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
05:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
m1@m1-desktop:~$


but if I add the fourth (in this case the ID GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac ), then the system falls. Here what I see in dmesg


[   98.722227] nvidia-modeset: Allocated GPU:0 (GPU-43453088-0fca-9442-106d-7594d157ebf2) @ PCI:0000:01:00.0
[   98.769072] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769117] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769144] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769169] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769193] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769217] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769241] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.359255] nvidia-modeset: Allocated GPU:1 (GPU-5c9c8e29-a088-90a6-2a20-b2b2b971d1fb) @ PCI:0000:05:00.0
[   99.398991] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399035] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399063] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399087] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399112] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399136] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buff er], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399160] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.984670] nvidia-modeset: Allocated GPU:2 (GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac) @ PCI:0000:06:00.0
[  100.619118] nvidia-modeset: Allocated GPU:3 (GPU-d099b67e-f204-66fa-96dc-365a6b559a7e) @ PCI:0000:03:00.0
[  100.743159] NVRM: GPU at PCI:0000:01:00: GPU-43453088-0fca-9442-106d-7594d157ebf2
[  100.743162] NVRM: GPU Board Serial Number:
[  100.743164] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 000001e0 00000801 00000004 00000005
[  100.743649] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000004 00000005 00000004
[  102.432593] r8169 0000:07:00.0 enp7s0: link up
[  102.432600] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready
[  103.743306] nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
[  103.773941] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
[  105.501795] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[  105.501798] Bluetooth: BNEP filters: protocol multicast
[  105.501802] Bluetooth: BNEP socket layer initialized
[  105.613048] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
[  105.613106] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
[  105.704570] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
[  105.704972] BUG: unable to handle kernel paging request at ffff88167153d830
[  105.704974] IP: [<ffffffffc0262880>] _nv008171rm+0x620/0x780 [nvidia]
[  105.705052] PGD 220c067 PUD 0
[  105.705053] Oops: 0000 [#1] SMP

Three days I try to solve a problem.
I changed versions of BIOS (0325,0608,0610) and risers, control 4G is included, has updated NVIDIA drivers to 381.22 - nothing helps.
Maybe somebody will have ideas?

My guess is your mobo is trying to / is using SLI.  Are you using an M2 ssd?

There should be some setting in the bios related to SLI; disable it / what slots are you using and are you using risers, if so on which GPUs?

If you are using risers; how are they powered?

[1714150177]

1714150177

[1714150177]

1714150177

[1714150177]

1714150177

[1714150177]

1714150177

[tempgoga]

Does anyone know of a way to detect GPU memory vendor information in Linux?  Similar to how GPU-Z can display the info in Winblows.  I want to group my mining rig clusters based on GPU memory vendors.  I think this will dramatically help in improving stability when tweaking each card in each rig. 

I wish there was a way, i've been looking for over a week now, maybe it can only be done on windows? or maybe the tool/command just doesn't exist on linux yet?

[fullzero]

I think you are using too low of a powerlimit and this is preventing higher OC from making a difference.

What powerlimit are you using?

When dual mining you need to use a higher powerlimit; ensure:

Code:

POWERLIMIT="YES"            

POWERLIMIT_WATTS=125

 or higher maybe up to 135 .  I don't have any ASUS GTX 1070 Turbos so I don't know what is OPT for them.

########

Interesting when I first set up rig 7x cards used 1150 watts.  

When I had PL set to 125  the power use dropped to 985w at the wall.

Now if I turn PL off or use 135 or 140 there is zero change at the wall it still uses 985w.

When terminal boots up I can see the PL come up but I have a theory that it is stuck at 125 and not changing.

Is that possible?

I have another rig that I just set up with 4 cards and it uses 785w regardless of the power setting.  On that rig the correct setting shows when terminal spools up but it is not limiting power. With 125 on each card I thought it should be 700 w max.

Any ideas on if PL can get 'sticky' ?

do not use the master setting  use individual.  for each card  and try
124
125
126
124
125
126

Indidivual powerlimits might work if you are having trouble with the primary powerlimit.

If that doesn't work try:

SLOW_USB_KEY_MODE="YES"

and see if that solves the problem.

[fullzero]

Does anyone know of a way to detect GPU memory vendor information in Linux?  Similar to how GPU-Z can display the info in Winblows.  I want to group my mining rig clusters based on GPU memory vendors.  I think this will dramatically help in improving stability when tweaking each card in each rig. 

Let me know if you find this out.

[xleejohnx]

I will hold off on integrating this for now then (and wait for your changes); in the meantime I will make a link to your repo on the OP.

I've committed an update that, if it pans out, rolls everything into one Python script...no auxiliary shell scripts.  I'm testing it right now to verify that it behaves the same as the previous version.  I suspect I'll know in the morning.

Edit: Just did some accelerated testing by manually switching to a less-profitable coin first...the script killed the miner and fired up the appropriate miner.  I think the most recent update is ready for wider testing:

https://gitlab.com/salfter/nvoc-nicehash-switcher

Looks good; I will probably change this py a little when I integrate it to make it read all the variables from oneBash.

I like the sound of this even better!!!

[f00ch0w]

Seems like the 6pin powered risers didn't solve the issue. Rig did work stable for longest period now, think it was something over 24hrs. Plugged out 1 GPU to see is 6x GPUs causing it to crash... Every GPU was on separate cable on PSU but still crashed... Out of ideas now

EDIT: Now my x4 1070 rigs are crashing too. Same shit all over again, Either GPU1/2/3/4 has stopped working bla bla, crashes the whole rig... Can anyone provide me with a solution?

Also, I've got a Gigabyte H110-D3A on those 1070 rigs, could that be the issue? Put one as a test back on AsRock to see for a test, will let ya know

EDIT2: Yep, AsRock didnt make a difference. Sometimes it crashes with a freeze

[smokinggun46]

Love this OS.   

I've been using a new mobo:  Biostar Z270GT6; got it to work all day yesterday on 5 GPUs.  Tinkered a bit today, tried to boot mobo, got pass BIOS screen, then got spammed with PCIE bus error severity=corrected.  It just spammed and spammed non stop, and would probably never stop if I hadn't powered down. 

A similar issue that is answered can be found here: https://askubuntu.com/questions/771899/pcie-bus-error-severity-corrected 

PS:  32GB USB still has some imaging issues, I've tried reformatting without the "quick" option, and tried both NTFS and FAT32. 

did you change picie to gen 2 in the bios?

On Biostar Z270GT6, the only option for selecting gen1,gen2,gen3 are under something called "max-link".  When doing initital setup, I wasn't sure what "max-link" is and the description didn't have any clues on PCIE. 

But i managed to get nvOC to boot up by using a different USB (same brand, same type, ordered 2).  Im reluctant to reboot mobo at least for another 3-4 days!

[S9k]

Hi,

Please help!
I have got stuck on this problems  
My configuration:

-ASUS PRIME Z270-P - 2 . I tried both, results are similar.
-EVGA GeForce GTX 1080 GAMING ACX 3.0 - 2
-MSI Geforce GTX 1080 Gaming X-  2
-The Gigabyte power supply unit on 1200 watts


Three video cards work perfectly in any any combinations,

m1@m1-desktop:~$ nvidia-smi -L
GPU 0: GeForce GTX 1080 (UUID: GPU-43453088-0fca-9442-106d-7594d157ebf2)
GPU 1: GeForce GTX 1080 (UUID: GPU-d099b67e-f204-66fa-96dc-365a6b559a7e)
GPU 2: GeForce GTX 1080 (UUID: GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac)
m1@m1-desktop:~$

m1@m1-desktop:~$ lspci |grep VGA
01:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
03:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
05:00.0 VGA compatible controller: NVIDIA Corporation Device 1b80 (rev a1)
m1@m1-desktop:~$


but if I add the fourth (in this case the ID GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac ), then the system falls. Here what I see in dmesg


[   98.722227] nvidia-modeset: Allocated GPU:0 (GPU-43453088-0fca-9442-106d-7594d157ebf2) @ PCI:0000:01:00.0
[   98.769072] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769117] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769144] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769169] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769193] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769217] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   98.769241] ACPI Warning: \_SB_.PCI0.RP04.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.359255] nvidia-modeset: Allocated GPU:1 (GPU-5c9c8e29-a088-90a6-2a20-b2b2b971d1fb) @ PCI:0000:05:00.0
[   99.398991] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399035] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399063] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399087] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399112] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399136] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buff er], ACPI requires [Package] (20150930/nsarguments-95)
[   99.399160] ACPI Warning: \_SB_.PCI0.RP05.PXSX._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
[   99.984670] nvidia-modeset: Allocated GPU:2 (GPU-5aacd4db-f68b-917e-8ac2-84caf68d6cac) @ PCI:0000:06:00.0
[  100.619118] nvidia-modeset: Allocated GPU:3 (GPU-d099b67e-f204-66fa-96dc-365a6b559a7e) @ PCI:0000:03:00.0
[  100.743159] NVRM: GPU at PCI:0000:01:00: GPU-43453088-0fca-9442-106d-7594d157ebf2
[  100.743162] NVRM: GPU Board Serial Number:
[  100.743164] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 000001e0 00000801 00000004 00000005
[  100.743649] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000004 00000005 00000004
[  102.432593] r8169 0000:07:00.0 enp7s0: link up
[  102.432600] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready
[  103.743306] nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
[  103.773941] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
[  105.501795] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[  105.501798] Bluetooth: BNEP filters: protocol multicast
[  105.501802] Bluetooth: BNEP socket layer initialized
[  105.613048] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
[  105.613106] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
[  105.704570] NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000000 00000080 00000000 00000005 00000004
[  105.704972] BUG: unable to handle kernel paging request at ffff88167153d830
[  105.704974] IP: [<ffffffffc0262880>] _nv008171rm+0x620/0x780 [nvidia]
[  105.705052] PGD 220c067 PUD 0
[  105.705053] Oops: 0000 [#1] SMP

Three days I try to solve a problem.
I changed versions of BIOS (0325,0608,0610) and risers, control 4G is included, has updated NVIDIA drivers to 381.22 - nothing helps.
Maybe somebody will have ideas?

My guess is your mobo is trying to / is using SLI.  Are you using an M2 ssd?

There should be some setting in the bios related to SLI; disable it / what slots are you using and are you using risers, if so on which GPUs?

If you are using risers; how are they powered?

Hi,
no, I don't use M2 SSD.
I use risers of the version 006s with the molex socket.

I managed to solve a problem. I modified / etc/default/grub



m1@m1-desktop:/etc/default$ more grub
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
#GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="vga=0 rdblacklist=nouveau nouveau.modeset=0"
GRUB_CMDLINE_LINUX=""

sudo update-grub

also I have created the file  disable-nouveau.conf which contains two lines

m1@m1-desktop:/etc/modprobe.d$ more /etc/modprobe.d/disable-nouveau.conf
blacklist nouveau
options nouveau modeset=0

sudo reboot

[salfter]

I will hold off on integrating this for now then (and wait for your changes); in the meantime I will make a link to your repo on the OP.

I've committed an update that, if it pans out, rolls everything into one Python script...no auxiliary shell scripts.  I'm testing it right now to verify that it behaves the same as the previous version.  I suspect I'll know in the morning.

Edit: Just did some accelerated testing by manually switching to a less-profitable coin first...the script killed the miner and fired up the appropriate miner.  I think the most recent update is ready for wider testing:

https://gitlab.com/salfter/nvoc-nicehash-switcher

For some odd reason since you consolidated all the code to the switch.py, now the only miner that runs is equihash.

Mine's been running daggerhashimoto almost exclusively since the latest release.  Looking at current-profit, we have:

Code:

neoscrypt: 0.00122266 BTC/day (3.14 USD/day)
lyra2rev2: 0.00044478 BTC/day (1.14 USD/day)
daggerhashimoto: 0.00221102 BTC/day (5.67 USD/day)
lbry: 0.00039243 BTC/day (1.01 USD/day)
equihash: 0.00163831 BTC/day (4.20 USD/day)
pascal: -0.00003248 BTC/day (-0.08 USD/day)

I now have it logging the data (instead of overwriting it), and I have the current unpaid balances at NiceHash.  I'll let it keep running and see what happens.

[lbrasi]

I will hold off on integrating this for now then (and wait for your changes); in the meantime I will make a link to your repo on the OP.

I've committed an update that, if it pans out, rolls everything into one Python script...no auxiliary shell scripts.  I'm testing it right now to verify that it behaves the same as the previous version.  I suspect I'll know in the morning.

Edit: Just did some accelerated testing by manually switching to a less-profitable coin first...the script killed the miner and fired up the appropriate miner.  I think the most recent update is ready for wider testing:

https://gitlab.com/salfter/nvoc-nicehash-switcher

For some odd reason since you consolidated all the code to the switch.py, now the only miner that runs is equihash.

Mine's been running daggerhashimoto almost exclusively since the latest release.  Looking at current-profit, we have:

Code:

neoscrypt: 0.00122266 BTC/day (3.14 USD/day)
lyra2rev2: 0.00044478 BTC/day (1.14 USD/day)
daggerhashimoto: 0.00221102 BTC/day (5.67 USD/day)
lbry: 0.00039243 BTC/day (1.01 USD/day)
equihash: 0.00163831 BTC/day (4.20 USD/day)
pascal: -0.00003248 BTC/day (-0.08 USD/day)

I now have it logging the data (instead of overwriting it), and I have the current unpaid balances at NiceHash.  I'll let it keep running and see what happens.

I am noticing if something other than equihash is more profitable in "current-profit" it does kill the equihash mining processes but fails to start anything else.

[salfter]

For some odd reason since you consolidated all the code to the switch.py, now the only miner that runs is equihash.

Mine's been running daggerhashimoto almost exclusively since the latest release.  Looking at current-profit, we have:

I am noticing if something other than equihash is more profitable in "current-profit" it does kill the equihash mining processes but fails to start anything else.

I manually switched to equihash, let it get up and running, and then fired up the script.  It killed the equihash miner and restarted the daggerhashimoto miner.

You are aware that the miner runs in a screen session, right?  When the script switches from one algo to another, the screen session associated with the first miner ends and a new one is started with the second miner.  screen -dr miner will bring up the currently-running miner.

[lbrasi]

For some odd reason since you consolidated all the code to the switch.py, now the only miner that runs is equihash.

Mine's been running daggerhashimoto almost exclusively since the latest release.  Looking at current-profit, we have:

I am noticing if something other than equihash is more profitable in "current-profit" it does kill the equihash mining processes but fails to start anything else.

I manually switched to equihash, let it get up and running, and then fired up the script.  It killed the equihash miner and restarted the daggerhashimoto miner.

You are aware that the miner runs in a screen session, right?  When the script switches from one algo to another, the screen session associated with the first miner ends and a new one is started with the second miner.  screen -dr miner will bring up the currently-running miner.

I was able to resolve the issue by removing all the old mine_ALGO.sh files from the /media/m1/1263-A96E directory.  I assumed these would not interfere with the new switch.py script.

[Nexillus]

Putting up another rig here soon. Going to test out the mining Algo switching that was just put out a few pages back.

Anyone have suggested settings for 1060s? Saw some on the first page but wanted to see if anyone else has some.

[salfter]

I was able to resolve the issue by removing all the old mine_ALGO.sh files from the /media/m1/1263-A96E directory.  I assumed these would not interfere with the new switch.py script.

I wouldn't have thought those would interfere as the new script shouldn't call them, but I "git rm"'d them before the latest commit.  Odd.

[gig410]

My rig crashed from having the settings too high, it went down when I was asleep. I rebooted it and it's up and running but I'm getting a low disk space warning. What file / directory do I delete ?

run this code line and you are golden on space

Code:

sudo apt-get purge $(dpkg -l linux-{image,headers}-"[0-9]*" | awk '/ii/{print $2}' | grep -ve "$(uname -r | sed -r 's/-[a-z]+//')")

that worked. Thank you so much!

Thanks for helping xleejohnx

gig410 what version are you using?

Im using 0017, sorry for the late response.

[UberDaemon]

@ fullzero  

here is a really detailed build of the nvoc0017  with 2 nvidia 1070's on a

GIGABYTE GA-Z270P-D3 LGA1151 Intel Z270 2-Way Crossfire ATX DDR4 Motherboard.

to all this is a solid board  really good

I tested stable up to 5 amd rx 480's  on win 10 and smos
I tested stable up to 4 1080 ti's on win 10 and win 7  tested up to 3 on nvoc

I am sure it will do 5  on all of the above well maybe not win 7.  I just did not test that high on all os's

https://bitcointalk.org/index.php?topic=1998198.0

Can I ask: why do you go for the higher end CPU?

I've been running 2 eth rigs on Asrock H81 Pro BTC boards for over a year, mostly using Ethos (which is an AMD linux mining distro). I recently started to convert to Nvidia so I'm using the same setup but one of them now using nvOC and 2 1070s + 3 1060s. I always used the cheapest low end pentium (I forget exactly which - 2 cores 3.3GHz) and it was always fine. Seems fine in nvOC so far too. Unless you want to run that XMR CPU miner I guess.

I went a step lower than Pentium on my 2 rigs and bought $50 G3930 Celeron processors since I am only GPU mining.  They run nvOC quite stably (I just returned from a 5 day vacation and both of my rigs that were running v0016 stayed up the entire time I was gone).  Granted, I am not using Teamviewer like some folks here.  That will consume more system resources.  I can do everything I need with SSH and the screen command if I'm at home.  I did leave one of my windows workstations online while I was gone so I could teamviewer into that and from there SSH into my rigs if necessary, but luckily I had no need to. 

[UberDaemon]

Also, I couldn't find how I can see the current mining process. I did see the screen -r commands, but that implies killing the current process and restarting it. I'd like to be able to see, from SSH, the current mining process without killing it. Is this possible?

If you want to monitor the mining process via screen you're going to have to kill the initial gnome-terminal.  There's no way around that, as screen can only reconnect to an existing screen session.

This shouldn't be a big deal if you have a stable rig.  You only need to do it once per reboot.  My process is:

1. From my desktop where I monitor my rigs I initiate a constant ping:

Code:

ping -t 10.20.30.40  # substitute your rig's IP, find it in your router, or by running nmap on your LAN subnet, or by running ifconfig from a guake terminal on the rig if you have a monitor connected

2. Boot the rig
3. Wait until I begin to get ping responses from the rig, thus indicating Ubuntu has booted and rig has network connectivity
4. SSH into the rig (user: m1  password: miner1)
5. Initiate a screen session:

Code:

screen -s [name for your rig, make one up or call it "rig"]

6. Start nvidia-smi dmon to watch for mining process to begin (by waiting until this happens you know OC settings, fan speed settings, etc have been applied.  Running those commands from within screen isn't 100% consistent IME as I always see error messages when I tried it that way.  It's best to let those settings commands run from gnome-terminal as Ubuntu first boots IMO).

Code:

nvidia-smi dmon

7. Wait until you see wattage go up and GPU utilization go up to 100% (which indicates that the oneBash script concluded and opened the mining process).  Exit nvidia-smi with CTRL + c
8. Find the PID for gnome-terminal.  

Code:

ps aux | grep gnome-terminal

9. Kill it:

Code:

kill [PID from step 8]

10. Restart mining:

Code:

bash '/media/m1/1263-A96E/oneBash'

It might seem like a lot of steps, but it takes all of 120 seconds and you shouldn't need to do it very often once your rig is dialed in.  You're losing maybe 1 minute's worth of hashes on avg of every week?  Pretty negligible considering the convenience of monitoring from another workstation, and you're not using up system resources by using Teamviewer.  This also lets you go completely headless if you buy a dummy HDMI plug.  I just updated from 16 to 17 and didn't need to haul my extra monitor upstairs to do it.  Easy peasy.

[UberDaemon]

Seems like 6x pin powered risers solved my issue with 1050ti's crashing. Thanks a lot @fullzero and others

Now, I'm interested, is there a way to see all rigs on API and to be able to see that from outside network? If so, how to configure it with router? I got a MikroTik behind the 24-port switch.

Best way to do this is to setup a OpenVPN into the network and allowing it on the same subnet. Once you VPN, the connection will act just like if you were on the home network. It will also be secure if you use higher level of encryption like AES256-CBC.

You could just use SSH for this if you don't want to setup a VPN server, as SSH also uses AES-256 encryption and is every bit as secure as VPN, plus it's already running!  The only config required would be to apply a static DHCP lease in your router so each miner always has the same LAN IP assigned to it, and to also forward appropriate port(s) in your router (i.e. you could for instance set am unused incoming WAN port like 2222 to forward all inbound traffic on that port to LAN port 22 (default SSH port) on LAN IP 10.20.30.40 if that were the LAN IP for your nvOC rig.  If you have multiple rigs 2222 forwards to port 22 on 10.20.30.40, WAN port 2223 forwards all incoming traffic to LAN port 22 on IP 10.20.30.41, etc).  My only concern here though is that I would want to change the default password (miner1) before opening up an outside port to nvOC's SSH daemon as a clever hacker might scan your WAN IP (which is a thing, bored people/malicious people do this) and find that open port and get lucky somehow by trying "miner1" as a password.  Changing the system password is as simple as running passwd from guake/SSH, but I wouldn't recommend doing that until OP can give some guidance on if that will cause problems within oneBash.  Most of the commands executed in oneBash require privilege escalation and I don't know where it finds the "miner1" password.

OP, can you shed any light on that?  Is it okay to change the password for the m1 user without editing anything else?  I don't see it inside oneBash itself.

[IAmNotAJeep]

First of all big thank you to fullzero and everyone contributing to this distro!

I've been struggling with the Genoil crash issue and lack of watchdog implementation for the past few days and I have a bandaid solution that seems to be actually working quite well, perhaps it can help others in the community:

Essentially you need to split the Genoil output to a file, grep it (we only care about 'error' instances only ;  and then this output as input for a monitoring script that kills and restarts the misbehaving process.

So we have 2 scripts launched in screen as daemons "ltail" script and "ett" script

$screen -dmS ltail sh ~/eth/Genoil-U/ltail
and
$screen -dmS ett bash ~/ett

ltail:
--------------------------
#!/bin/bash
echo listening...
cd ~/eth/Genoil-U/
tail -fn0 err.log | \
while read line ; do
        DATE=$(date +%d-%m-%Y" "%H:%M:%S)
        echo "$DATE $line" | grep "error" | tee -a ~/eth/Genoil-U/timestamp.log
        if [ $? = 0 ]
        then
                kill $(ps aux | grep '[e]thminer' | awk '{print $2}')
                sleep 1
                screen -dmS ett bash ~/ett
        fi
done
-------------------------
ett:
-------------------------
#!/bin/bash
cd ~/eth/Genoil-U
./ethminer -U -F eth-us.dwarfpool.com:80/0xBEbd092a03827C37B75cd4ea314b207AA65c348f/208 2>&1 | tee >(grep error --color=never --line-buffered | tee -a err.log)

-------------------------

finally I also send output of ltail to timestamp.log to track how many times Genoil fails per hour - with roughly aiming at 1 crash per hour this gives me about 130MHs out of 5xGTX1060 which is a good 20+ MHs higher then Claymore... most importantly it gives stable hashing despite the OC introduced errors. The recovery is literally seconds.
Oh yeah and I also run
$tail -f ~/eth/Genoil-U/timestamp.log in a screen as well as watch -n 5 'sensors |grep Core' in another screen to fine tune the OC vs crash per hour vs temp
Hope this helps, and I hope the message is not too chaotic.
Cheers!

BTC: 13PnEKpfVzNseWkrm6LoueKcCMPj74zPv7
ETH: 0xBEbd092a03827C37B75cd4ea314b207AA65c348f

[TheCoinMine]

Sort of a broad question here, but anyone have any suggestions to why my mobo wont turn on? everything seems like its connected properly, probably screwed the switch up or the pins for the switch. just wondering if anyone encounters semi generic problems or common issues? its a 270 board.