Topic: [ mining os ] nvoc (Read 418523 times)

Am a newbie to mining and setting up my first rig.  Have an extensive Windows background.  Have zero Linux background (except for the immersion course I'm in the middle of trying to get nvOC v2.0 set up and running ).

I got nvOC up and running but my issue is, somewhere along the way, the LAN controller ceased being recognized.

My setup:

• Attempting a 6-card build with all 1080ti's, largely following Vosk's "How to Build a 6x 1080 TI Mining Rig with ATX & Server PSU's" (https://www.youtube.com/watch?v=2MxNVySpbcw)
• Motherboard = Gigabyte Z270P-D3
• PSU (to power risers) = EVGA Supernova 650 P2
• PSU (to power cards) = Bitmain APW3++
• Harddrive = Lexar 32G USB 3.0 memory stick

I'm initially working to get one card set up and running.  It is plugged into a riser that is connected to the primary PCI slot on the mobo, both of which (riser and card) are powered by the EVGA PSU (once I get one card running I'll work up to all six cards and then power the risers solely with the EVGA and the cards with the Bitmain).  I have the most current BIOS for the mobo installed, 1bash is configured to mine SMART and I can boot & have the miner software functioning.  But my current issue is that the LAN controller is not visible to the OS.

I've had fits and starts thru this process, re-imaging the USB probably 4 or 5 times, for various things I hadn't done correctly (e.g., hadn't updated the BIOS before booting, had plugged my monitor into the mobo HDMI instead of the cards's HDMI and dealt with Xorg issues, etc.).  I know that at one point, the LAN controller was working (green light flashing on controller, which BTW, is a Realtek® GbE LAN chip (10/100/1000 Mbit))-- I'm just not sure when it quit working to be able to exactly determine what I might have changed that caused the issue.

Diagnostics & Steps I've Taken To Address

• Re-imaged nvOC
• Reset CMOS (including pulling mobo battery for about 30 minutes)
• ifconfig -a only shows a "lo" entry, no WLAN
• sudo lshw -c network flashes "PCI (sysfs)" real quickly and then flashes "USB" real quickly and then returns to the command prompt
• And yes, I have tried plugging in an ethernet cable that was live and working in another computer sitting right next to my rig

I guess the issue could be a fried controller, but this is a brand new mobo.  The only other thing I did differently at one point was change the mouse I was using from a USB mouse to an older wireless mouse where the wireless receiver plugs into the light green mouse port on the back of the mobo instead of being a USB mouse.  But I've re-imaged, reset CMOS, etc. since then and even went without using a mouse on a couple of attempts to see if that had caused some issue.

Anyway, I would greatly appreciate any assistance and guidance the Community might have to offer.

Thank you!

Thank you, do you know why i get this :

COIN/ALGO not found, Check your settings
Miner not started, Stopping watchdog

my settings

X16R_COINS="RVN"

Change:
X16R_MINER="ZENEMYminer"

to:
X16R_MINER="T_Rex"

--
Tigel

COIN="RVN"

# Raven Coin (RVN)
RVN_ADDRESS="infowire.RVNMiner1"
RVN_EXTENSION_ARGUMENTS="-p x -a x16r"
RVN_POOL="rvn.suprnova.cc"
RVN_PORT="6666"
RVN_WORKER="$WORKERNAME"

How do i use the trex miner for RVN ? i see in in folder but its not in 1bash ?

Different cuda versions shown by nvcc and nvidia-smi:

CUDA has 2 primary APIs, the runtime and the driver API. Both have a corresponding version (e.g. 8.0, 9.0, etc.)

The necessary support for the driver API (e.g. libcuda.so on linux) is installed by the GPU driver installer.

The necessary support for the runtime API (e.g. libcudart.so on linux, and also nvcc) is installed by the CUDA toolkit installer (which may also have a GPU driver installer bundled in it).

In any event, the (installed) driver API version may not always match the (installed) runtime API version, especially if you install a GPU driver independently from installing CUDA (i.e. the CUDA toolkit).

The nvidia-smi tool gets installed by the GPU driver installer, and generally has the GPU driver in view, not anything installed by the CUDA toolkit installer.

Recently (somewhere between 410.48 and 410.73 driver version on linux) the powers-that-be at NVIDIA decided to add reporting of the CUDA Driver API version installed by the driver, in the output from nvidia-smi.

This has no connection to the installed CUDA runtime version.

nvcc, the CUDA compiler-driver tool that is installed with the CUDA toolkit, will always report the CUDA runtime version that it was built to recognize. It doesn't know anything about what driver version is installed, or even if a GPU driver is installed.

Therefore, by design, these two numbers don't necessarily match, as they are reflective of two different things.