[ mining os ] nvoc

[papampi]

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

Why do not you use a lighter linux system like Lubuntu or even, a linux system even more minimalist as there are at least a dozen ...

I know, I say in a vacuum and it's a lot of work but I have often thought about it. I did not have the courage or the motivation to try.

These days, I'm getting ready to make my RIG fatter because 2 GPU is good for testing, but it does not produce enough and not fast enough for my taste.

I don't notice any Sol/s difference as long as the desktop is not being actively used (all my rigs are headless anyway).

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

I think the only thing left to reduce size and improve stability (maybe?) is abandon Desktop

I thought the same thing but the problem is that nvOC is an easy to use mining system. I think it won't be easy to use for lots of people if you remove gnome desktop or another desktop interface. A lighter interface desktop would be a better solution.

An Xorg instance needs to be running on each GPU (which is what nvidia-xconfig -a or --enable-all-gpus does) for nvidia-settings to change clocks and fan.

Can you share how you run nvOC in full headless mode without losing Xorg.
Any steps necessary for first run ...

May be we can add an option in 1bash for that mode.

[papampi]

Another goal was to make the system effectively read-only. Best of all - to run from RAM, but also an option - to run from compressed read-only file system (squashfs) with overlay in RAM, still having read/write partition to save settings, but only by request.

The idea was:
- boot from flash;
- run and save non-persistent changes/logs to ram;
- withstand any power losses with no risk to damage the file system;
- if any changes required, make them and save to flash overlay (emulated by a file on FAT file system).

Cloning of this system will be as easy as make a bootable flash and copy there squashfs file system image, kernel image and casper r/w file with changes (or simply put miners and settings to FAT for Windows users). And it could not be broken with power loss. So, nothing should be written to flash unless explicitly requested.

nvOc v0019-2.0 uses tmpfs for miner, watchdog, temp control, wtm, ... logs.
Only important temp control and watchdog logs saves to disk so you can check after reboot

[papampi]

nvOC v0019-2.0 Community Release new shrinked image Mega.nz
Download Link

Beta testing...
Please test and let me know.

Change Log:

Code:

Image size: 11 GB
ZIP size: 3.8 GB
Auto Expand to full size on first boot
Fixed copy 1bash from fat partition to SSD/HDD on first boot
SHA256: ACCA9787169E6E722ED74FB02DBE1C44E7760CEB537CB79D4C61C7FFF8AD3057

Ok, i will download it and upload on dl.free.fr. Why don't you use google drive. A lot of users had some problems with Mega in the past.

My drive is almost full, Sorry.
Problem with Mega was when size is over 5 GB and it triggers the wait, bellow 5 GB should be no problem.

Here is another link to download this new image :
http://dl.free.fr/lkvBjGvPn

You can also Download here :
http://dl.free.fr/5sjQBr/Atomicomunity

NB : I don't verify before uploading and after downloading but i don't détect any problem since these opérations.

Thanks added your link toGitHub

[akokkon]

what is the default password of nvoc m1 user on v0019-2.0 Community Release?

[osnwt]

nvOc v0019-2.0 uses tmpfs for miner, watchdog, temp control, wtm, ... logs.
Only important temp control and watchdog logs saves to disk so you can check after reboot

That's great! Especially, if it mounts main FS r/o. I don't think so, though. Had no issues with the old one (put logs to tmpfs), but had issues with some of miniPC ARM boards where r/w mount of /etc (and rootfs) on SD card or internal flash in case of power fail event could lead to unrecoverable /etc data that was mounted r/w but had no writes and was writeable by root only. So if possible, I would like to mount main fs r/o.

Anyway, great system to start.

[papampi]

what is the default password of nvoc m1 user on v0019-2.0 Community Release?

user: m1
password: miner1

[Rig4p]

I have now added 2 GTX1060 GPUs to my rig that previously had only one GTX1080.
Hash rates look reasonable but I noticed that both of the GTX1060s were running below their expected power numbers, ~62W vs. 75W.
The GTX1080 is still running around 200W as before I added these two and that is expected.
So I monitored the "screen -r temp" printout for a while and noticed this:

Code:

ERROR: Error assigning value 75 to attribute 'GPUTargetFanSpeed' (m1-desktop:0[fan:2]) as
       specified in assignment '[fan:2]/GPUTargetFanSpeed=75' (Unknown Error).

I see a similar message that mentions the other GTX1060.
Is this problem occurring possibly because I have mixed GPUs now?
Do I need to set individual OC/power numbers?

Thanks for the help.

[CryptAtomeTrader44]

Thats exactly what Leenoox says to use Lubuntu or some thing lighter.
But I think changing OS needs fullzero consent and its not our place to fully change his OS.

Ubuntu 18.04 is coming in less than 3 months
lets see how it works with gnome-desktop and new kernels, and hopefully fullzero will show up till then too.

nvOC boots in less than a minute and I dont see any reason to migrate from it and go for lubuntu or any thing else when ubuntu has the most users and many are familiar with it.

Only reducing the weight of the image for first. That will facilitate downloading and flashing. This reduced weight would permit smaller USB KEY too.

As was mentioned above by another contributor, a script that will be added to a normal version of ubuntu would be largely superficial. Not necessarily need to download a complete system as currently. It would suffice to say that it must install these scripts packages on ubuntu VIRGIN

For Fullzero, will we see him coming back one day?
Nothing is less sure.

I know we've already talked about all this, but the more time passes and the more difficult it is to continue without giving you access to you and other coders like Leenoox and Stubo or others I probably forget . You can not even edit the description of the thread and readers are forced to type in the entire thread to understand what is happening. Not really optimized all that.

I'm just a user, but I still read posts that say they downloaded version 19-1.4 instead of yours.

[leenoox]

Exactly.

My test rigs on Win10. Ignore stale share counts, I have long pings from these test rigs.
rig01 is ethminer, rig02 is Claymore's, rigmon is my own tool and uses the same API for both miners.



PS. NVidia cards on Linux report temps/fans only in CUDA mode (tested with older miner for CUDA 8 ). In OpenCL mode they do not report this.

This looks amazing and we would love to merge your rigmon into nvoc. Moreover, we would love if you could join the dev team and help further improve nvoc.
nvoc has thousands of users, great and active community that provides feedback and gratitude so it will be great platform for your project.

We've been looking to add some sort of remote monitoring and management but it keeps being pushed aside as we work on further improving and bug fixing the core nvoc scripts.

It would be great to use your tool as a starting point (instead of starting from scratch) and we could further expand it to add management options like on the fly change of mining coin, OC adjustments, reboot, 1bash creation trough GUI, etc.

If interested in joining the dev team please contact papampi for details or at least share the code to be merged if you don't have time for further development. Thanks.

[NameTaken]

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

Why do not you use a lighter linux system like Lubuntu or even, a linux system even more minimalist as there are at least a dozen ...

I know, I say in a vacuum and it's a lot of work but I have often thought about it. I did not have the courage or the motivation to try.

These days, I'm getting ready to make my RIG fatter because 2 GPU is good for testing, but it does not produce enough and not fast enough for my taste.

I don't notice any Sol/s difference as long as the desktop is not being actively used (all my rigs are headless anyway).

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

I think the only thing left to reduce size and improve stability (maybe?) is abandon Desktop

I thought the same thing but the problem is that nvOC is an easy to use mining system. I think it won't be easy to use for lots of people if you remove gnome desktop or another desktop interface. A lighter interface desktop would be a better solution.

An Xorg instance needs to be running on each GPU (which is what nvidia-xconfig -a or --enable-all-gpus does) for nvidia-settings to change clocks and fan.

Can you share how you run nvOC in full headless mode without losing Xorg.
Any steps necessary for first run ...

May be we can add an option in 1bash for that mode.

I'm actually using a different Ubuntu based OS: https://ba.net/zcash-eth-miner-os/. I like it because it's almost stock Ubuntu 16.04 with the latest Nvidia driver preinstalled and I use Ansible-playbook for configuration management. An xorg.conf is generated every boot before X starts with this systemd service file:

Code:

[Unit]
Description=Generate xorg.conf
Before=lightdm.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/nvidia-xconfig -a --cool-bits=28 --allow-empty-initial-configuration

[Install]
WantedBy=multi-user.target

[leenoox]

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

Why do not you use a lighter linux system like Lubuntu or even, a linux system even more minimalist as there are at least a dozen ...

I know, I say in a vacuum and it's a lot of work but I have often thought about it. I did not have the courage or the motivation to try.

These days, I'm getting ready to make my RIG fatter because 2 GPU is good for testing, but it does not produce enough and not fast enough for my taste.

I don't notice any Sol/s difference as long as the desktop is not being actively used (all my rigs are headless anyway).

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

I think the only thing left to reduce size and improve stability (maybe?) is abandon Desktop

I thought the same thing but the problem is that nvOC is an easy to use mining system. I think it won't be easy to use for lots of people if you remove gnome desktop or another desktop interface. A lighter interface desktop would be a better solution.

An Xorg instance needs to be running on each GPU (which is what nvidia-xconfig -a or --enable-all-gpus does) for nvidia-settings to change clocks and fan.

Can you share how you run nvOC in full headless mode without losing Xorg.
Any steps necessary for first run ...

May be we can add an option in 1bash for that mode.

In nvoc running headless doesn't mean you don't start X11. The Desktop is running, it just doesn't have monitor attached to it. nvidia drivers require X11. I believe there is a way to not fully load desktop with xinit and start the miner from tty. This way the X server will start but it will not load Unity or Gnome. Just not enough time to play/test this for now...

[leenoox]

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

Why do not you use a lighter linux system like Lubuntu or even, a linux system even more minimalist as there are at least a dozen ...

I know, I say in a vacuum and it's a lot of work but I have often thought about it. I did not have the courage or the motivation to try.

These days, I'm getting ready to make my RIG fatter because 2 GPU is good for testing, but it does not produce enough and not fast enough for my taste.

I don't notice any Sol/s difference as long as the desktop is not being actively used (all my rigs are headless anyway).

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

I think the only thing left to reduce size and improve stability (maybe?) is abandon Desktop

I thought the same thing but the problem is that nvOC is an easy to use mining system. I think it won't be easy to use for lots of people if you remove gnome desktop or another desktop interface. A lighter interface desktop would be a better solution.

An Xorg instance needs to be running on each GPU (which is what nvidia-xconfig -a or --enable-all-gpus does) for nvidia-settings to change clocks and fan.

Can you share how you run nvOC in full headless mode without losing Xorg.
Any steps necessary for first run ...

May be we can add an option in 1bash for that mode.

I'm actually using a different Ubuntu based OS: https://ba.net/zcash-eth-miner-os/. I like it because it's almost stock Ubuntu with Nvidia driver preinstalled and I use Ansible-playbook for configuration management. An xorg.conf is generated every boot before X starts with this systemd service file:

Code:

[Unit]
Description=Generate xorg.conf
Before=lightdm.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/nvidia-xconfig -a --cool-bits=28 --allow-empty-initial-configuration

[Install]
WantedBy=multi-user.target

This is not the best solution as the nvidia-xconfig doesn't fully optimize the xorg.conf. I am working on something similar to this, a new script to generate xorg.conf on every boot before starting X.
The main problem, especially with with those 19 GPU motherboards is that BusId is not correctly assigned with the static xorg.conf that we are using. On any mobo when adding/removing cards the Bus is changes... plus there are some busid numbers skipped (used for other PCIe devices) and it is different on all mobos.
The script will use lspci to find all nvidia GPU's and create new xorg.conf with proper busid values assigned and all other tweaks that nvoc uses. Hopefully this will fix the problems like booting into black screen with cursor, booting into pink screen, etc

[NameTaken]

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

Why do not you use a lighter linux system like Lubuntu or even, a linux system even more minimalist as there are at least a dozen ...

I know, I say in a vacuum and it's a lot of work but I have often thought about it. I did not have the courage or the motivation to try.

These days, I'm getting ready to make my RIG fatter because 2 GPU is good for testing, but it does not produce enough and not fast enough for my taste.

I don't notice any Sol/s difference as long as the desktop is not being actively used (all my rigs are headless anyway).

root partition wont allow to go lower, So I think its the smallest we can get.
But will try to cleanup the OS again, see if I can reduse more.

I think the only thing left to reduce size and improve stability (maybe?) is abandon Desktop

I thought the same thing but the problem is that nvOC is an easy to use mining system. I think it won't be easy to use for lots of people if you remove gnome desktop or another desktop interface. A lighter interface desktop would be a better solution.

An Xorg instance needs to be running on each GPU (which is what nvidia-xconfig -a or --enable-all-gpus does) for nvidia-settings to change clocks and fan.

Can you share how you run nvOC in full headless mode without losing Xorg.
Any steps necessary for first run ...

May be we can add an option in 1bash for that mode.

I'm actually using a different Ubuntu based OS: https://ba.net/zcash-eth-miner-os/. I like it because it's almost stock Ubuntu with Nvidia driver preinstalled and I use Ansible-playbook for configuration management. An xorg.conf is generated every boot before X starts with this systemd service file:

Code:

[Unit]
Description=Generate xorg.conf
Before=lightdm.service

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/nvidia-xconfig -a --cool-bits=28 --allow-empty-initial-configuration

[Install]
WantedBy=multi-user.target

This is not the best solution as the nvidia-xconfig doesn't fully optimize the xorg.conf. I am working on something similar to this, a new script to generate xorg.conf on every boot before starting X.
The main problem, especially with with those 19 GPU motherboards is that BusId is not correctly assigned with the static xorg.conf that we are using. On any mobo when adding/removing cards the Bus is changes... plus there are some busid numbers skipped (used for other PCIe devices) and it is different on all mobos.
The script will use lspci to find all nvidia GPU's and create new xorg.conf with proper busid values assigned and all other tweaks that nvoc uses. Hopefully this will fix the problems like booting into black screen with cursor, booting into pink screen, etc

I have 6 GPU rigs so that hasn't caused any problem although I do plan on building 8 and 12 GPU rigs in the future. That 19 GPU boards seems like it has more problems than it's worth.

https://forum.hiveos.farm/discussion/36/asus-b250-mining-expert

[leenoox]

This is not the best solution as the nvidia-xconfig doesn't fully optimize the xorg.conf. I am working on something similar to this, a new script to generate xorg.conf on every boot before starting X.
The main problem, especially with with those 19 GPU motherboards is that BusId is not correctly assigned with the static xorg.conf that we are using. On any mobo when adding/removing cards the Bus is changes... plus there are some busid numbers skipped (used for other PCIe devices) and it is different on all mobos.
The script will use lspci to find all nvidia GPU's and create new xorg.conf with proper busid values assigned and all other tweaks that nvoc uses. Hopefully this will fix the problems like booting into black screen with cursor, booting into pink screen, etc

I have 6 GPU rigs so that hasn't caused any problem although I do plan on building 8 and 12 GPU rigs in the future. That 19 GPU boards seems like it has more problems than it's worth.

https://forum.hiveos.farm/discussion/36/asus-b250-mining-expert

Actually that is a good picture in the above link showing the busid's. Note how the busid's (first column) are 1, 2, 3, then 6, 7, etc. nvoc's static xorg.conf uses busid's 1, 2, 3, 4, 5, etc. This is what I am trying to correct and create dynamic xorg.conf with properly assigned busid's. I am not sure if it will fix the problems with Asus B250 Mining Expert or not (I don't have this board, I will ask for beta testers once the script is done), but this problem of improperly assigned busid's affect most other boards as well (however, they still work because current nvoc xorg.conf has settings for 19 cards, not gonna go into more details here, it's a big topic), and occasionally nvoc will not boot or will not overclock some card.

[urnzwy]

How to setup telegram for nvoc0019

First of all install Telegram, you can have it on almost all operating systems: Windows, Mac, Linux, Android, iOS, ...
Open your telegram and send /newbot to @BotFather
To send message to @botfather, click the search (magnifying glass) and search for @botfather, when found click start and send message /newbot
It will ask for name, send your desired bot name EX.  Mining Rigs Info
Then it ask for a username for your bot , send your desired unique username EX. papampi_mining_nvoc0019
it will give you an HTTP API token EX.     HTTP API: 408504581:AAHen-E4peZrlVhJx-GlnADyiVDgGiR4O8g
Put it in your 1bash  like this :

Code:

TELEGRAM_APIKEY="408504581:AAHen-E4peZrlVhJx-GlnADyiVDgGiR4O8g"

Now send /getid to @myidbot same search process for @botfather
Click start, then send /getid
It will give you a 8 digit number put it in 1bash :

Code:

 TELEGRAM_CHATID="97994065"

Click the Start in your new bot
Thats it.
You will get some info every 30 min. and alerts from watchdog
You can edit your telegram file and get more info
I will send my edited telegram for more info later today.

Man I cannot get this to work. Did exactly as above and tried to use the ./telegram cmd to test. But nothing comes through. I don't have to edit any other files in the OS right? It should work with my bot & ID?

My TELEGRAM_MESSAGES loads the following

m1@m1-desktop:~$ bash /home/m1/7telegram
Telegram Messages for nvOC v0019-2.0 - Community Release
Version: :v0019-2.0.001


New Telegram in 3600 seconds

[osnwt]

This looks amazing and we would love to merge your rigmon into nvoc. Moreover, we would love if you could join the dev team and help further improve nvoc.
nvoc has thousands of users, great and active community that provides feedback and gratitude so it will be great platform for your project.

We've been looking to add some sort of remote monitoring and management but it keeps being pushed aside as we work on further improving and bug fixing the core nvoc scripts.

It would be great to use your tool as a starting point (instead of starting from scratch) and we could further expand it to add management options like on the fly change of mining coin, OC adjustments, reboot, 1bash creation trough GUI, etc.

If interested in joining the dev team please contact papampi for details or at least share the code to be merged if you don't have time for further development. Thanks.

Sorry, I definitely have no time to make any promises for participation. I think we have different visions for its development. I like 1bash to be separated into smaller scripts (clocks, miners, etc) and put under git control to update remotely and apply automatically (suggested it to the original author, but think it was not implemented for a reason). But for newbies maybe easier to have all in one and no git.

I may consider sharing the code of rigmon as is, if you find it useful. It does not have currently a comprehensive manual, but there are some comments in the sample config. I am ready to answer questions and do minor changes I need (like miner autodetect). I intentionally did not use websockets to update, use polling instead - it may be reconsidered too. Remote management might be good but you have to provide authentication (maybe you already have it, as I said, I don't use nvOC as it was designed, I only use it as a kernel+video drivers with power/clock management, use own scripts to start anything).

[leenoox]

Thats exactly what Leenoox says to use Lubuntu or some thing lighter.
But I think changing OS needs fullzero consent and its not our place to fully change his OS.

Ubuntu 18.04 is coming in less than 3 months
lets see how it works with gnome-desktop and new kernels, and hopefully fullzero will show up till then too.

nvOC boots in less than a minute and I dont see any reason to migrate from it and go for lubuntu or any thing else when ubuntu has the most users and many are familiar with it.

Only reducing the weight of the image for first. That will facilitate downloading and flashing. This reduced weight would permit smaller USB KEY too.

As was mentioned above by another contributor, a script that will be added to a normal version of ubuntu would be largely superficial. Not necessarily need to download a complete system as currently. It would suffice to say that it must install these scripts packages on ubuntu VIRGIN

For Fullzero, will we see him coming back one day?
Nothing is less sure.

I know we've already talked about all this, but the more time passes and the more difficult it is to continue without giving you access to you and other coders like Leenoox and Stubo or others I probably forget . You can not even edit the description of the thread and readers are forced to type in the entire thread to understand what is happening. Not really optimized all that.

I'm just a user, but I still read posts that say they downloaded version 19-1.4 instead of yours.

Ubuntu is heavyweight OS and it's desktop Unity is nothing but trouble. Even Ubuntu is abandoning Unity in its next release and are switching to Gnome which is even heavier (but more stable). I doubt we need a full featured desktop environment for mining purposes. Why carry all that heavy and resource hungry desktop environment when we don't really need it.

If we want to stay within the Ubuntu ecosystem my proposal was to switch to Lubuntu which is using LXDE desktop which is much lighter and less resource hungry than Ubuntu's Unity. But... Lubuntu is switching from LXDE to LXQT in the next release in few months which is even greater and doesn't make sense to build, apply tweaks and optimize it when in few months will change its core system.

We are stuck at crossroad with Ubuntu and its derivatives (Lubuntu) at the moment as major changes and new LTS versions are coming in 3 months time, not worth the effort to rebuild nvoc on a new base Ubuntu system now.

On the other hand, as my opinion is not very favorable towards any Ubuntu (or derivative) as being built for masses and thus introduce features that create overhead and inherit bugs we don't really need in mining OS (Bluetooth, printers, sound, media), I am leaning towards building linux from scratch by using Manjaro Architect (Arch linux based) or start with plain Arch linux and add only what we need in the mining world (latest kernel for greater hardwer support, light desktop, compilers, script support, php, Perl, etc.), which will shed all junk and bloatware that comes with Ubuntu and will be extremely light, responsive and easy on resources.

In my opinion this would be natural progression of nvoc as we will transfer everything from nvoc into a new base system with the added benefits of better hardware support (latest kernel), security (latest software updates), compatibility with new miners (CUDA 9.1), stability, less resources, etc. The beauty of Arch linux is the use of rolling system which means there are no new releases, there are no releases and end of life, the system is always the latest, you can take years old image and will bring itself up as if it was installed today with all latest software and packages.

In my opinion this will not steer away from fullzero's beliefs or nvoc's open source way but will help us keep nvoc up to date with bleeding edge hardware support and up to date softwate.

I am not saying that this will be easy or can happen overnight. There is a lot of work to custom build Arch linux, apply tweaks and adapt nvoc's scripts to the new ecosystem but once it's done we will have rock solid mining OS without any bloatware that will have very small image to download and could probably use only few gigs of space.

If there's enough interest and positive feedback on this, I could start working on it

[jintruder]

leenoox, excellent, you have green light from my side !!!!

One question : Does nvOC support server failover for Claymore's miner ??

Another question : Is it possible to find out somehow the exact steps which fullzero applied to transform the original ubuntu image into nvOC ?

[NameTaken]

I hear the opposite where Unity is quite stable while GNOME crashes more often. That's from using them as normal desktops which you probably aren't going to do with a mining rig anyways. As for resource usage, I don't think that's a big concern since most mining rigs have 4 or 8GB of RAM and running Unity + miner uses less than 2GB. I don't think switching to Arch is a good idea. Closed source miners are compiled for Ubuntu and running them in Arch will result in miss and/or wrong shared libraries.

[salfter]

I've had some issues recently with nvOC eating itself when Ubuntu pushes out an upgrade.  Mostly it's updates to the nVidia drivers with mismatched libraries or something similar keeping miners from starting.  The timing of the first two such incidents was particularly bad, as the first was right before I left for a cruise.  I thought I'd fixed it, but it ate itself again a day or two later while I was somewhere off the coast between Long Beach and Ensenada.  

I've kinda always had a bit of a preference for Gentoo.  It's what most of my Linux boxes run (other than the Raspberry Pis, and I've even had Gentoo running on those from time to time), and it's what I'm most comfortable handling.  I put an M.2 SSD back in my mining rig, got Gentoo up and running, and knocked together some ebuilds for the latest versions of several GPU miners.  (The sp-mod ccminer needed some fixes to build against CUDA SDK 9, and I've also patched it so that it exits on the first SIGINT (like every other miner) instead of requiring you to press Ctrl-C twice.)

I pulled in my MiningPoolHub switcher, and with changes to the miner paths (they all live in /usr/bin now), it works as it does on nvOC.  I currently have the GPU fans on automatic, but I might port the fan-control code in nvOC to run the fans faster to keep the GPUs cooler.

I've also benchmarked the different miners and algorithms again to see which ones are faster, and this might be of interest to nvOC users.  The single-purpose miners (ktccminer-cryptonight, EWBF's equihash miner, and ethminer) are the fastest at their respective algorithms.  Of the various forks of ccminer (tpruvot, sp-mod, KlausT, and alexis78), for the algorithms I've currently configured to mine at MiningPoolHub, sp-mod is faster at 5 algorithms (groestl, neoscrypt, qubit, skein, and x11) and tpruvot is faster at 3 (keccak, lyra2v2, and myr-gr).  A table of what miner supports what and which miner is faster is at https://home.alfter.us/s/58BNGWUTxfpvr5U; yellow indicates an algorithm supported by only one miner, while boldface indicates the fastest miner I benchmarked on my four 1070s.

I don't have my new system wrapped up in a tarball that you can download and dump onto a flashstick as with nvOC; that isn't really the Gentoo way.  You can, however, recreate it for yourself.  Install Gentoo as you normally would (I used the amd64 no-multilib profile), install Layman, use Layman to install my Portage overlay, install the miners, and install my MiningPoolHub switcher.  A shell script launched from within /etc/local.d (or a cron job) can be used to run the switcher periodically.

Next up: benchmark the algorithms available at zpool that I don't already have in the config.