What are you trying to do, keep your original SSD partitions and write nvOC as a new, separate partition? What do you have in your second partition, another operating system, or just data?

Or... just occured me: if you are sure your 1bash settings are correct and you don't need to change anything else, simply copy this file over to your next installations. You will need to flash the nvOC img file anyways, would take about the same amount of time as cloning.

This whole process I mentioned is worth it only if you customize other things after booting nvOC, not just 1bash.

For Windows the process would be similar: let's say you have your notebook with Win10. Plug the source drive in one USB port, the destination drive in another USB port, and run a disk cloning utility. That same disk cloning utility should allow you to create an image file to save on your notebook itself, to flash future drives. Check this website for some disk cloning utilities for Windows:

http://lifehacker.com/5839753/the-best-disk-cloning-app-for-windows

Now for your other questions:

1) Never had this kind of problem. My setup uses DHCP but with static IP assignments configured in my router, so there's a consistent hostname.

2) You PMed me with this question, but I'll reply here for others: if I understood, you wanted to know if it's possible to clone the nvOC installation before booting it at least once. I don't think it's a good idea, as there's that process to copy 1bash between partitions, adjusting them etc. (not sure if it still applies to v019). So just to be sure, boot it once, make sure it's mining correctly, then shutdown, and clone this installation.

3) I don't think you need to replace your USB drives unless they are giving read/write errors. After flashing and setting up everything, there aren't many disk writes that could wear out the drive, as far as I know.

After setting up the baseline nvOC installation, you could simply create a new image of the partitions (or entire disk), and use it to flash new disks. For that, you would need to boot from a different drive, as the disk you're going to image shouldn't be mounted. I personally like GParted Live and PartedMagic, as they are loaded with several utilities for that, but you could just use the "dd" utility that comes with every modern Linux basic installation.

So: boot GParted Live from USB stick; have the disk you are going to create the image from ready; have a disk where to save the image file ready; use a partition/disk cloning utility (or "dd") to create the image; use that image to flash new disks. Note that depending on your hard drive sizes, ideally you should create images with only the used space (some utilities allow that), as it doesn't make much sense to create a (say) 250 GB image with only 10 GB used.

Finally, I don't think you'd need to change anything on the newly-flashed nvOC disks, as it automatically adjusts the worker name based on the IP address (but of course you can), and the Xorg reconfiguration should be done automatically too.

Olá pessoal,

Não sei se é permitido anúncios aqui, mas como vi alguns, vou anunciar. (Moderação: se não for permitido, favor avisar que removo.)

Tenho um kit com 6 risers PCIe 1x / USB 3.0 à venda, novos, de excelente qualidade. Interessados, vide link:

http://produto.mercadolivre.com.br/MLB-890203191-baixou-kit-mineraco-riser-adaptador-pci-express-cabo-usb-_JM

Comprando diretamente comigo aqui, faço um bom desconto, pois aí não preciso pagar as taxas do MercadoLivre.

Abraços!

Hey man, that's a very nice DIY project you have there! And great schematics btw, thanks for sharing. I'm wondering, how much did it cost overall (Pi + fans + sensors and parts)? Did you try integrating it with nvOC's auto temp control, which uses the GPUs internal temp sensors, instead of relying on the DS18B20?

I'm facing some heating issues here, as the days are becoming hotter, so I'm thinking about what to do. I don't want to leave an A/C on all day, because of energy costs, so probably will need something to suck the hot air from the GPUs to the outside during the day, and reverse direction at night, when it's colder outside. Your project really gives some ideas...

The problem with never rebooting a Linux server has more to do with security, than with a technical need. There are many updates that require a reboot, the most obvious one being the Linux kernel itself (unless you use something like kexec or hot patching solutions, but even in these cases sometimes you need to reboot). Another case is when you update a service: you need to at least restart that service. Shared libraries updates is another critical situation: you need to reload *every* service that use these libraries, so they use the new versions.

I've been working with Linux for more than 15 years, and in some companies I've had to "struggle" with some people that kept saying "c'mon, Linux never needs a reboot!". Usually I just ran a vulnerability scanner on these servers and showed them the results.

Now for nvOC in particular, I'd say you don't need to schedule an automatic reboot through 1bash, but keep in mind the security updates: Ubuntu will usually tell you after applying some security updates when it needs a reboot.

nvOC supports CPU mining, but only for Monero (XMR), as far as I know. And it makes sense, as most (all?) of the other coins are not worth to mine with a CPU. Even Monero may not be worth it, unless you have free or very cheap energy...

How common is it for you to get cards of the same brand and model, but with different overclock capabilities? I've got 3 cards of the same brand and model, and for 2 of them, I can overclock the memory to +1500 MHz, but the other one can reach at most +1200 MHz. More than that, and it soft crashes after some time. It also runs a bit hotter than the others, requiring 5%~10% more fan speed to stay at the same temperature. I know there's the "memory lottery" (i.e. sometimes Samsung, sometimes Hynix etc.), but could this 300 MHz difference be considered "normal" if it's a lower-grade memory?

P.S.: I changed risers already, it's really the card. Don't know if it can be considered defective though, because at +1200 MHz it runs pretty stable.

Try a lower memory overclock offset: I get these errors when I overclock too much. To confirm, check the output of "dmesg" in the terminal; if you get messages like these:

[139035.343237] NVRM: Xid (PCI:0000:02:00): 31, Ch 0000001b, engmask 00000101, intr 10000000

Most probably that's the issue. If you get these messages but with a different Xid (in this example it's 31), report here, as each code has a different meaning.

Great!! But don't thank me for identifying this invalid entry in /etc/fstab, it was the merit of another user, as I mentioned, but I forgot his username! Nevertheless, Fullzero is aware of this, and said it will be fixed in v19.

Not to minimize your efforts on enabling swap, but the long boot time happens not because there's no swap, but because there's a swap entry in /etc/fstab that points to an invalid (non-existent) partition. Therefore, some init scripts invoked by systemd at boot time enter a wait loop, just in case this partition becomes available after some time. This invalid entry in /etc/fstab has been identified by another user here in the forum some posts ago, and just commenting it out solves the long boot time.

Now, if someone actually needs a swap partition, that's a different story... From my experience (and some other users as well), with 4 GB+ of RAM, there's no need of swap. I kept monitoring my RAM usage, even with Claymore's dual-mining, and it never came close to requiring swap. Now, going a bit more technical, if you were using your operating system in a different scenario (heavy multitasking, VM host, database server, desktop system where you need suspend-to-RAM etc.), you *may* benefit of a swap space even with enough RAM (and in case of suspend-to-RAM, you do need it, and at least the same size of your installed RAM), because the operating system may decide that it would be best to swap old memory pages to disk instead of purging them from RAM (and this "swappiness", in Linux, can actually be defined at runtime, i.e. you can instruct the kernel how agressively it should swap memory pages to disk). I don't think mining fits in these scenarios, and a swap space in a very slow medium like USB stick doesn't make much sense (I know in your case you used a SSD, but that's an exception). In Windows, Claymore requires a huge swap space because of different reasons (and Windows virtual memory management is different than in Linux).

I never needed to add swap to mine in Linux, using Claymore or whatever other miner. In nvOC, for instance, the RAM usage is very low, less than 2 GB, so if you have 4 GB or more of RAM (the minimum recommended, by the way), you shouldn't need a swap file or partition.

Hmm checking this Github repo, I see this is NOT the same as Genoil's ethminer (there's a FAQ explaining there). So, the question is... Does it perform better than Genoil's? Anyone actually tested?

Thanks for your answer scryptr! So, do you think the ASrock Z270 Killer Sli would work with a BIOS update? I couldn't find many reports of mining rigs with this board, but found one or two (and also a few complaining it didn't work). Its BIOS has the "TOLUD" setting, which I think is similar to the "Above 4G Decoding" setting necessary for 3+ or 4+ GPUs. The Asus Prime Z270-A I know is a sure shot, but much more expensive here...

Does anybody successfully setup a rig with 5+ GPUs (or know someone who has) with the following mobos:

ASRock ATX Z270 Killer SLI/BR (LGA 1151)

Gigabyte GA-990FX-GAMING (AMD AM3+)

They have a good price where I live (the Gigabyte AM3+ is because I have an old Phenom II CPU around, so would save some more money).

Thanks

Just type "top" at the terminal shell (e.g. the Guake terminal you access with F12). To quit top, type "q".

Regarding the powerlimit... That's very interesting! Looking forward for the "top" output I asked... I'm wondering if there's some sort of I/O queuing going on with the lower power limit (it will show as a high % of I/O wait or perhaps system usage). I suppose your hash rate also goes up a good amount by increasing the power limit, right?

@fullzero

Have you considered moving the configuration, or at least the key configuration parameters like pools and coin to mine, to a separate file? I sometimes change pools and coins, for instance, and currently I have several "1bash_xxx" files for each configuration, controlling the active one with a symlink to "1bash". One idea would be a config file like this (for instance in INI format, but just to illustrate):

::: 1bash.conf :::
[defaults]
# Every configuration option

# Below just what's different from default. Users define their config keys,
# specifying the active one in 1bash
[zec-nanopool]
COIN="ZEC"
ZEC_POOL="zec-us-east1.nanopool.org"

[eth-dwarfpool]
COIN="ETH"
ETH_POOL="eth-us.dwarfpool.com"

::: 1bash :::
# 1) Read default options
# 2) Read user options
USER_CONF="zec-nanopool"
...

Just an idea. I may be able to help you with that, if you want and find it a good idea. I know Bash doesn't have a built-in parser for INI (or whatever) config files, but there's some code around to do that.

It's OK to have a high CPU usage time* for kworker and irq/nvidia, these account for internal kernel worker threads and interrupts for GPU I/O (expected on a multi-GPU rig mining). What I'm really looking for is how much CPU usage is for user processes, system processes, and I/O wait, that's why I asked these values. Try this: run the "top" utility, it will be constantly updating -- type "1", it will expand the third line (CPU usage summary) to show each CPU. Then paste the values here, like that:

%Cpu0  :  0.3 us,  1.0 sy,  0.0 ni, 98.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
%Cpu1  :  0.3 us,  1.3 sy,  0.0 ni, 98.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
...
%CpuN  : ....

Regarding irqbalance, running the command I suggested, you should get one line like this:

root       874  0.0  0.0  19536  2232 ?        Ss   Aug06   0:12 /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid

* EDIT: high CPU usage TIME (which accumulates until the next reboot), not a constant high CPU usage percentual.

I don't have experience with your particular hardware, but from the specs of your CPU, it supports up to 16 PCIe lanes, so at least I/O shouldn't be a problem (https://ark.intel.com/products/90741/Intel-Celeron-Processor-G3900-2M-Cache-2_80-GHz), as long as you use all your cards with risers, so they all run at PCIe 1x.

You can check the following in your Linux installation:

1) In "top" or "system monitor", what's the breakdown of the CPU usage for USER, SYSTEM, NICE and WAIT? This will help identify where the bottleneck could be.

2) Which are the top 3 processes using more CPU?

3) Check if you have the process "irqbalance" running with the correct parameters: "ps aux | grep irqbalance".