Show Posts
|
Pages: [1] 2 3 4 5 6 7 »
|
Hello,
I am trying to upgrade a rig by adding a RTX 3070. The rig is running a mix of GTX 1060 and RTX 1660 For some reasons the RTX 3070 is not recognised by the system. I am running NVIDIA binary drivers 430.64 but still the RTX 3070 is not recognised
I suspect the problem is related to the diver that I am using. Is there a way to upgrade the driver version? I cannot find a way to install it on nvOC (Ubuntu 16.04)
Please help
|
|
|
Solved my problem,  but still cannot find the script that is launching the miners
|
|
|
Hello,
Just a quick question. I was restarting the rigs after several months of inactivity and cannot really remember all the configurations.
Which script is launching the miner? (with the parameters from 1bash) I am trying do diagnose a problem. I used to mine Eth with bminer. Now somehow my rig connects to the pool (ethermine), load the DAG for each card but shows 0 MH/s
Cheers Luca
|
|
|
Hello everyone Is the project still active? I didn't see a lot of activity recently Cheers Luca
|
|
|
@WaveFront I need you help for debugging the gpuinfo cmdlet, go into nvOC script @ line 206, replace the whole line with only "echo -e $INFO" and post results. Since it is talking about multibyte characters I have the suspect there is something wrong with the terminal character encoding. From which terminal you run the command? Hi Luke Sorry for my late answer. Changing the line as you instructed solved the problem. Thanks a lot :-D I am running the command from the standard "Terminal" app from macOS. Which terminal would you recommend? Here is the output: m1@m1-desktop:~$/home/m1/NVOC/mining/nvOC gpuinfo
ID,|,PS,|,T°,|,FAN,|,LOAD,|,POWER / LIMIT / MAX,|,GPUCLOCK,|,MEMCLOCK,|,VENDOR - MODEL 0,|,P2,|,69,|,90,|,100,|,75 / 75 / 75,|,1645,|,3802,|,NVIDIA - GeForce GTX 1060 6GB 1,|,P2,|,59,|,50,|,100,|,74 / 75 / 75,|,1582,|,3802,|,EVGA - GeForce GTX 1060 6GB 2,|,P2,|,69,|,60,|,100,|,75 / 75 / 75,|,1582,|,3802,|,ZOTAC - GeForce GTX 1060 6GB 3,|,P2,|,69,|,65,|,100,|,74 / 75 / 75,|,1695,|,3802,|,ZOTAC - GeForce GTX 1060 6GB 4,|,P2,|,70,|,80,|,100,|,74 / 75 / 75,|,1518,|,3802,|,NVIDIA - GeForce GTX 1060 6GB 5,|,P2,|,69,|,95,|,100,|,60 / 60 / 60,|,784,|,3802,|,ZOTAC - GeForce GTX 1060 6GB 6,|,P2,|,68,|,60,|,100,|,74 / 75 / 75,|,1594,|,3802,|,ZOTAC - GeForce GTX 1060 6GB 7,|,P2,|,69,|,70,|,100,|,74 / 75 / 75,|,1531,|,3802,|,ZOTAC - GeForce GTX 1060 6GB 8,|,P2,|,68,|,70,|,100,|,75 / 75 / 75,|,1594,|,3802,|,ZOTAC - GeForce GTX 1060 6GB 9,|,P2,|,70,|,65,|,100,|,75 / 75 / 75,|,1594,|,3802,|,ZOTAC - GeForce GTX 1060 6GB 10,|,P2,|,69,|,60,|,100,|,74 / 75 / 75,|,1569,|,3802,|,ZOTAC - GeForce GTX 1060 6GB 11,|,P2,|,69,|,95,|,100,|,60 / 60 / 60,|,797,|,3802,|,ZOTAC - GeForce GTX 1060 6GB 12,|,P2,|,69,|,90,|,100,|,74 / 75 / 75,|,1569,|,3802,|,ZOTAC - GeForce GTX 1060 6GB
m1@m1-desktop:~/NVOC/mining$
|
|
|
Hello, In the 3.2 version (installed from nvOC-3.2_Ubuntu-16.04_Cuda-9.2_Nvidia-418_2019-05-02-2.img), I have the feeling that there are bugs in the nvOC script. For example, when I run I get the error: column: Invalid or incomplete multibyte or wide character Am I the only person to have this error? Cheers Luca
|
|
|
Hey Luke,
Thanks for your answer. The partition auto-expand is starting automatically after first boot. Is there a way to stop partition auto-expand? I cannot find any option related to partitioning on 1bash
Cheers Luca
Hello Luke,
Didn't notice that I just have to edit the firstboot.json
Will try this.
Cheers Luca
|
|
|
Hello, I just tried to install nvOC 19-3.2, Ubuntu 16.04, Cuda 9.2, Nvidia 418, 2019-05-02
After the first boot, after resizing the partition, I get an error message:
error : unknown filesystem Entering rescue mode... grub rescue>
Is there anything I can do. What might be wrong?
cheers Luca
|
|
|
Hello all, I must be blind as a bat, but I cannot find the download image link of the latest stable version. Can you help me? Cheers
Have a look at nvOC GitHub Wiki Download-pre-built-OS-imagesThank you so much Papampi
|
|
|
Hello all, I must be blind as a bat, but I cannot find the download image link of the latest stable version. Can you help me? Cheers
|
|
|
Hello, I am considering upgrading from the 19-2.0 to the 19-2.1. How mature do you think the 19-2.1 is? Is it at an advanced beta stage or is it better to stay on the non beta 19-2.0 release?
|
|
|
@joykiller check that your connectors in motherboard pcie sockets do not touch each other.
You mean the x1 connectors? Those are not touching, the USB wires are, but its been like this now for over a year and had no issues. Yes, make sure the usb female connector of each x1 adapter is well spaced from the back contacts of the adjacent x1 connector board. It is a known issue for motherboards where each pcie socket is too close to the other one, like in the Asrock H110 Pro BTC+. I stopped having random gpus falling off the bus as soon as I covered each connector with isolating tape. You mean wrap the USB Cable in aluminium foil tape? Or you talking about the x1 Slot wouldnt that cause issues with conductivity on the board? Got a picture for reference please? I've seem'ed to get it working so far, its been going for over 24h so far as it has in the past year, but if the foil tape helps increase hashrate due to frequency noise maybe might be worth it. I got some tape laying around. No. What LukePicci was meaning is that in boards where the pcie connectors are close to each other, the side of the x1 connector, might touch the flat part of usb female connector of next x1 connector. This might disable the slot at best, or create short circuits. in order to prevent this you should place isolating tape on the side of the x1 connector. You should cover with tape the parts highlited in red in the picture.  If you exclude too aggressive overclocking, 90% of the instability problems on a rig are coming from poor power distribution. Two pieces of advice: 1) the pcie cable to SATA provided with the risers is generally of crappy quality. In any case the SATA connector cannot take more than 50-55W, so you should connect the pcie riser to a 6pin PCI cable directly to the power supply or through a pcie splitter.   2) If you have a dual power supply configuration, you should power the motherboard and all PCI risers with the same power supply. You will use the second power supply to power the top connectors of the GPUs only. This will prevent ground loops and many headaches.
|
|
|
I have a problem with one rig  It now boots into: /dev/sda2: recovering journal /dev/sda2: clean, 264109/901120 files, 2342988/3584000 blocks And seems stuck there for good I can still access the rig by SSH. Is there a way to recover the filesystem or should I already think about reflashing the SSD?
|
|
|
Hello,
Anyone using bminer to mine Ethash? Do you see any differences in hash rate between miner and ethminer? I tried to run them side by side, but I cannot see any noticeable difference in speed.
What do you think?
@CryptAtomeTrader44 said something about thet in some previous posts. I use Bminer because at the beta2 start, there wasn't been possible to use Claymore for NICE_ETHASH coin checking in WTM_PROFIT SWITCHING. I hadn't seen any hasrate différence between claymore and Bminer. Precisley, i mine only ETH, or ETC with Bminer. I saw it's possible tu DUAL mine with it, but i don't. I don't retry to mine on nicehash with claymore. Is seems to me that Bminer is slightly more stable. Hello and thank you for your answer. I was reading in forums that Bminer was way more effective than Claymore and Ethminer, so I thought about giving it a try. I cannot see any noticeable difference in hash rate (if you factor in the developer fee). Nevertheless, I see that Bminer has an integrated watchdog that catches GPU crashes pretty fast (not all of them), so overall efficiency is slightly better than ethminer. By the way, is there a way to generate a reported hash rate like with Claymore
|
|
|
Hello,
Anyone using bminer to mine Ethash? Do you see any differences in hash rate between miner and ethminer? I tried to run them side by side, but I cannot see any noticeable difference in speed.
What do you think?
|
|
|
Hey :-) What do you think is the ideal RAM size for a motherboard running nvOC?
Here is a look at how much it uses one one of my rigs with 7 1070's: m1@Miner1:~$ free total used free shared buff/cache available Mem: 8107204 1632364 5565128 42012 909712 6055112
As you can see, I have 8 Gb but it uses less than 2 in REMOTE (no local display). I tend to buy HW that I can re-purpose in the event that mining goes south, so I recommend running a single 8 Gb stick per mining host. I typically purchase them as a 16 Gb "kit" with 2 8 GB DIMMs. Clearly, you could go as low as 4 with no issues but I have no use for DIMMs that small outside of mining. Hi Stubo, Thanks for your answer. It's a good idea. the 16Gb kits can be cost competitive and easier to repurpose. Cheers Luca
|
|
|
Hey :-) What do you think is the ideal RAM size for a motherboard running nvOC?
|
|
|
Hello guys. First of all, big thanks to all the team for the great job on this project. Been using your Distro for 3 month now and it rocks guys. lately I've got an issue with one of my rigs, a faulty riser cause the rig to freeze without being able to complete it's reboot routing. As Doftorul pointed out more often than not having a GPU dropping off the bus triggers a kernel panic. So I'm sharing my workaround for those who got the same issue and have only a remote access to the rig: Create a magic reboot script that contain (magicreboot.sh) :#!/bin/bash echo 1 > /proc/sys/kernel/sysrq echo s > /proc/sysrq-trigger echo u > /proc/sysrq-trigger echo s > /proc/sysrq-trigger echo b > /proc/sysrq-trigger Edit 5watchdog :Change all the sudo reboot occurrence to sudo magicreboot.shDo the same in 6tempcontrolfor more reading about Sysrq: https://en.wikipedia.org/wiki/Magic_SysRq_keyHope this could help Big thanks to Doftorul, sizzlephizzle and all the nvOC team  Nice idea Have you tested it? I tried to implement R.E.I.S.U.B once but was not successful with a different approach. Does it need to sync twice? (u) remount the filesystem as read-only, dont think it can sync data to disk after u Isnt it better to do the full REISUB sequence? Edit; If you have a faulty GPU that causes system freeze can you please test this full REISUB sequence: #!/bin/bash echo 1 > /proc/sys/kernel/sysrq
# (un*R*aw) Takes back control of keyboard from X echo r > /proc/sysrq-trigger
# (t*E*rminate) Send SIGTERM to all processes. echo e > /proc/sysrq-trigger
# (k*I*ll) Send SIGKILL to all processes. echo i > /proc/sysrq-trigger
# (*S*nc) Sync all cached disk operations to disk echo s > /proc/sysrq-trigger
# (*U*mount) Umounts all mounted partitions echo u > /proc/sysrq-trigger
# (re*B*oot) Reboots the system echo b > /proc/sysrq-trigger Yeah I've Tested it for 2 days now and the rig reboot as soon as there's a GPU lost, preventing it from freezing. At first I was issuing only : echo 1 > /proc/sys/kernel/sysrq and echo b > /proc/sysrq-trigger and it do work then Doftorul suggested that I go with the SUSB sequence I think the 2nd (S)ync wont do any thing as system is mounted as read-only in previous (U)mount step. Can you please check the full REISUB and see how it works .. Hey, very interesting subject. After several tries, I approached the kernel panics problem with a hardware solution. I have a RaspberryPI, with one of the GPIOs, interfaced to the reset pins of the motherboard. The RPI checks every 30 seconds the status of the SSH port of the rig (I find it more reliable than just pinging the mobo). If the mobo is unresponsive for more than 10 minutes the RPI resets the rig. I will publish the RPI scripts and schematics as soon as I have 10 minutes :-D
|
|
|
Bad news about Equihash : Bitmain launch Equihash ASIC this day. 10 KSol/s consumming only 300W ! What do you think about this ASIC ? https://shop.bitmain.com/product/detail?pid=00020180503154806494uGcSyiu806FDI said that I do not come to promote them, I did not buy ASIC but it is quite clear that this case will pose a huge problem. Much worse than that of the ETH miner of the same company. Only the Monéro community reacted in opposition to the bitmain ASICS. I simply wish to have your opinion on this issue which may make GPU mining obsolete on this algorithm rather quickly. At this rate, only Neoscrypt and Cryptonight V7 will remain to be mined via CPU and GPU. Not a good deal for decentralization as a cryptocurrency target. One rig 22mhX6 for 132MH drawing 680w VS 10Kh @300W is going to be a threat? Where? Oh and each unit does cost 2K and you can only have one for now. Hmmmmm. thay Its equihash not ethash ... For Ethash there is the Antiminer E3. Price and power consumption is not radically better than a GPU rig with an equivalent hash rate
|
|
|
Will add other new cryptonight miners to next version For now to use latest xmr-stak: First Download and compile latest : cd /home/m1/ git clone https://github.com/fireice-uk/xmr-stak.git mkdir xmr-stak/build cd xmr-stak/build cmake .. make install
make install may take long time to complete Rename xmr-stak to be compatible with rest of nvOC scripts mv /home/m1/xmr-stak/build/bin/xmr-stak /home/m1/xmr-stak/build/bin/xmr-stak_miner
0miner change the old To: if [ $COIN == "XMR-OLD" ]
incase we need it .... Add new XMR to 0miner: if [ $COIN == "XMR" ] then HCD='/home/m1/xmr-stak/build/bin/xmr-stak_miner' ADDR="$XMR_ADDRESS" screen -dmSL miner $HCD --currency monero7 --noCPU --noAMD -o "$XMR_POOL:$XMR_PORT" -u $ADDR -r $XMR_WORKER -p $MINER_PWD -i 0 fi
In above you can change "-i 0" to the port number for web ui if you want cpu mine too remove noCPU If you want it showing hashrate by default in output, after 1st run edit /home/m1/config.txt Change : To: Edit: I missed stubo wrote a how to before in This PostThanks mate # Configure Memory for hugepages sudo nano /etc/sysctl.conf # Add line # Set user limits sudo nano /etc/security/limits.conf
# Add lines * soft memlock 262144 * hard memlock 262144
# Reboot Hi Papampi, thanks for the detailed instructions. It works like a charm :-)
|
|
|
|