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).

Please add a telegram chat. I hate web-based messengers, but many people I know use telegram for many coins and services (Bitcoin Atom, Victorium coin, Coinomi wallet are some to name). Would be happy to join official Intense Telegram group.

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.

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.

That's exactly the reason why I dropped ideas of making thin system. For AMD I did a USB-bootable one that required 1GB USB flash only, and only 500M of this was the compressed file system, the remaining space was allocated for copy-on-write overlay fs to save changes.

I always prefer to build my mining linux myself. But for nvidia, I wasn't able to control undervoltage/overclocking. That's why I still use old nvOC. But from what I remember, these functions required from me to install X11 along the computing drivers. So I am not sure if desktop makes it so fat and not a required dependencies. Without them the system works, but was no fine tuning possible. I may be wrong.

The issue is I don't know which miners provide an API to get the info desired. I know at the moment that all Claymore's miners (ETH, ZEC, XMR), ZM Zcash miner, ethminer provide the data (ZM does not report fans, but reports temperatures). I know nothing about others since I do not use them.

It was a fun project, now I'm playing with trading bots :-)

Forget about ethmon, as explained in one of its issues, it was abandoned and not developed anymore.

I rewrote it and called rigmon, it supports quite a lot, including RRD-like database for FAN/TEMP graphs, miner console view, etc, etc. (see that issue for more details). But I did not publish it and use internally. Writing a code for public requires some time to add README, examples, etc, etc. But only couple of users said thanks for it, not talking about donations... User interest is the main motivation for OpenSource projects, and I did not find such interest. So I decided to not waste time preparing it for public access and did not open.

rigmon supports multiple miner rigs with few cards per each, Claymore dual-mining, also it supports multiply miner groups to see group stats plus total. Supports miner console view (for Claymore and ZM). Customisable window title with rates. API call for external health monitoring (when there are issues, I receive a message on my phone via telegram and another Android-specific AutoRemote tool, rigmon provides the info, another script uses it).

Actually it is not an all-in-one solution as some other monitors. I wrote it for myself and find it useful. I do not need, say, miner control from it, so it lacks this. Recently added ZM API support and just found ethminer compatibility.




PS. How to post small image previews? I used img tag and they are huge...

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.

Actually I am using Claymore's ETH miner in single mode. This night I tested ethminer 0.13 and found that it outperforms Claymore's one a little bit (even not counting the devfee). But I like to monitor it via API using own tools. I surprisingly found that latest ethminer is compatible for miner_getstat1 API call, but it requires CUDA 9. Older version for CUDA 8 works well, but it does not yet provide the same telemetry. That's the reason I want to upgrade. Newer version also works in OpenCL mode but hashrates are much lower than in CUDA mode.

I've been using nvOC for more than a year. I do not upgrade the base system, but upgrade only miner I use. Now I am going to switch to another miner which requires CUDA 9 (my system has CUDA 8.0).

Can anybody suggest me how to update CUDA to version 9 not touching the rest of the system? I can, of course, replace or update the whole nvOC and check if it has CUDA 9 (does it?), but prefer to update drivers only.

I have never used Linux as a desktop with graphic drivers (but use it heavily for console only servers), so have no experience with NVidia drivers.

Ok, so someone (some only pools) had time to build and run testnet, but others are not.
Sources still are not available to build and check.
Wallets not available even in the form of full nodes to build and play with.
Doesn't look fair. Looks like dirty games.
Seems I have to out either.

Windows AMD drivers do not like patched VBIOS (of video cards), that can be fixed with atikmdag-patcher (that patches drivers).

But UEFI motherboard may not boot system at all if it is in SecureBoot mode and VBIOS was patched. It also may not recognise videocards with patched BIOS if in UEFI mode, thus, may require CSM enabled.

I have never seen such issues (but once I was not able to boot Linux USB flash until enabled BIOS CSM mode in the MB setup). But such issues may occur, so the README for BIOS editor on GitHub explains this. It does not mean that you definitly will have issues, it just means that tou might have them, and explains how to fix.

That comment about tweaks is equally applicable to any BIOS mod.

When you change BIOS, its cryptography signature becomes invalid. If you have SecureBoot enabled in the MB settings, it will not boot because GPU firmware seems to be "compromised". CSM means Compatibility Support Mode for UEFI BIOS, it may be required to boot non-UEFI firmware (or firmware with wrong checksum/signature).

So if it's required, it will be for any version of editor, or better said, for any modified video BIOS.

It has nothing with Claymore's ETH dual miner.
There is Claymore's miner for CryptoNight (Monero, Intense, etc).

From what I can guess, it uses memory somehow. More memory - more threads to mine CN. But is that a real limitation - I don't know. Also it has an option to double memory used to improve performance. You should test if you want more memory or not, it depends on your system.

And that's right.
Wallet is not a miner. It may include a CPU-miner as a part of the node to check pools and/or testnet. But the main goal of coin developers should be the coin itself and related services, not a hardware-optimised miners, I think.

Yeah, my bad. That was @ Cryptopia.

Another one solution is DigiByte (DBG). Cheap and fast transactions. Used it to withdraw to Poloniex.

I talked about every wallet from the quoted download link for Intense Coin:

I said nothing about other coins.

Not a GPU, but every wallet is able to mine. There is a "Start mining" button, pressing that it will CPU-mine.