Topic: [ mining os ] nvoc - page 289. (Read 418549 times)

BUMMER! A warning would have been nice.

You've probably changed hostname? You have to add the new name to Xorg. If so, see http://ubuntuhandbook.org/index.php/2016/06/change-hostname-ubuntu-16-04-without-restart/

My guess is X isn't running; or isn't running properly. 

Install from scratch.

Then make sure it is not attached or you will kill it

Hi @fullzero

when I recently upgraded my rig to run nvOC 0018, it did something nasty to an ssd that was connected to the rig which had a Windows 8.1 install on it. I remember reading something after it booted about how it was doing something to Windows partitions, and now if I remove the USB stick so the BIOs tries to boot from the SSD it says something like "NO OPERATING SYSTEM INSTALLED".

I do like to be able to swap to Windows to try out different things - do you have any idea how I may be able to repair the SSD so Windows will boot again? Or do I just have to go through the pain of installing it from scratch and unplug it when I use nvOC?

In the v0018 1bash it does; in this updated version it only logs restarts.  This is because logging slightly decreases stability with using USB keys.  I will make watchdog logs a YES/NO option for the next 1bash.  For now you can open the watchdog file:


go to line 86:


and remove the # so it reads:


and it will log soft crashes.

I added logic based on Avarets experience with P106-100 (I don't have any of these so I am going on your report Avarets; let me know if these changes work)

Please let me know if there are any issues with these updates.

Love the v0018 release and all the functionality!  

However, POWERLIMIT NIGHTMARES!  

I have one major issue, I cannot lower the POWERLIMIT.  I run 8 rigs of 1050Ti and 125W is just way to high.  I have tried adjusting the base line and the individual POWERLIMIT settings and I am still seeing maximum power being utilized in NVIDIA-SMI and TEMP CONTROL.  I thought maybe the TEMP CONTROL was trumping the setting, but I don't think that is the case (at least based on what my 46 year old brain and eye balls looking at the 1bash code understands).  I thought maybe it was the correction in line 527, but that didn't change anything.

I tried "NO" for both WATCHDOG and TEMP CONTROL with POWERLIMIT set below MAX for the 1050Ti and I still see max power output.

I did notice during startup, of the three terminal screens that pop-up during startup that the second terminal session has the POWERLIMIT set correctly at 60.   However, something happens after the third terminal screen initiates (miner starting) that pushes the POWER back to MAX.

I added another rig of 1050Tis tonight and I saw more unusual behavior from POWER settings again where GPU0 goes to 125W as the max power limit and the rest of the GPUs all complied with my setting of 65Watts.   I have no idea what is causing this inconsistency in power limit settings.

I also noticed in the Guake terminal that the TEMP CONTROL module is displaying continuous notifications that 125W is not a valid power limit (even after changing the settings in the module to 60-65).

I normally run all my rigs at 60W, which keeps the current draw low enough to run 3 rigs of 8 GPUs on each 15 AMP circuit.  Also, extremely efficient.

I am still hunting for what is causing the forced 125W power setting.

The settings are in the quote you posted; also on the OP:

ensure Mining Mode is enabled in the bios. LINK to PICTURE 

ensure Max TOLUD is set to 3.5 GB in the bios. LINK to PICTURE

NOTE: you must first only connect 6x GPUs, boot, make Bios changes, save and reboot, shutdown, add the other 6x GPUs, attach the USB or SSD and boot

Connect a monitor to the GPU connected to the 16x slot; nvOC and rxOC do not currently support integrated graphics.

If they are all powered off; I'm not sure what would have caused that.

If they are still on / but not mining:

I would look at one and see if there is a connection problem with the pool.  This is the most likely reason for a large number of rigs to simultaneously stop mining.

pool disconnect detection and mitigation / auto failover can be improved in a later version

Right now; if the pool server goes down: the rig will reinitialize 1bash 5 times then, reboot.  This will occur in a larger loop until the pool server is reachable.  

This occurs because when the pool is not providing work, the GPU utilization will be below 90.

FIrst: ensure you have made the 2x bios changes as indicated in the OP for this mobo; and saved / restarted as directed.  If you have made additional bios changes then you should restore the default settings and perform the procedure in the OP. 

Second while troubleshooting I recommend attaching the GPU with output to the primary 16x slot and using 11 of the mining GPUs in the other slots.  Run in local mode.

If you have significantly changed the GPU configuration; especially in regard to the the primary GPU it is likely the system will need to restore the xorg and reboot.  If it does this once it is expected; if it does this in a loop (ie multiple times in a row there is a problem).

Let me know how this goes.

PS: I highly recommend using the ASRock 13x mobo to get out the box; easy setup.  If I was having a lot of trouble with this mobo, I would get one of the ASRock and then return the Biostar when I had the rig running with 13x.

BaliMiner please provide a BTC address for the next version.

I still need to add some more ccminer versions; v0018 doesn't have the version I believe you are looking for.