Gnomuz

I raised that issue a few posts above, but the problem is tzdata is not included in the official docker, which is out of reach for the author of this template ... So, the TZ variable is just ignored. I only run a harvester on the docker, and it communicates properly with my full node/famer, despite the container is in UTC time and the full node in "Europe/Paris", 2 hours behind just like you. There's a manual workaround to have the correct time, but you have to redo each time you restart the container : - entrer the container console - stop all chia processes : 'chia stop -d farmer' - install tzdata : 'apt-get update' and 'apt-get install tzdata', there you can set the timezone - restart chia : 'chia start farmer' * change 'farmer' in the commands above according to the set of process you run in the container. For me, it's 'harvester' to run 'chia_daemon' and 'chia_harvester' only. 'farmer' is fine for a full node, farmer, harvester and wallet. Hope that can help, although I doubt your sync issues are related with timezone. I'm almost sure everything is managed as UTC time at network level, and the timezone is only used to display timestamps in logs. If you don't open and forward the port 8444 to the container (in practice to the IP address of your Unraid server) on your router, you will have difficulties to connect to peers on the network, and thus the sync will take ages. It's exactly the same as in Bittorrent and many other P2P protocols. The oldest may remember the "Low Id" in emule 😉

Hi, Review the link I gave in my OP (https://github.com/Chia-Network/chia-blockchain/wiki/Farming-on-many-machines) to understand the underlying objectives. Step by step : - copy the mainnet/config/ssl/ca directory of your full node in a path accessible from the container, e.g. appdata/chia - edit the container settings : farmer_address : IP address of your farmer/full node machine farmer_port : 8447 harvester_only : true - start the container - enter the container console - enter "top", you should have only two chia processes : "chia_daemon" and "chia_harvester" - enter the venv : ". ./activate" - stop the running processes : "chia stop -d all" - check the processes stopped properly with "top" - create the keys for the container harvester signed by the farmer node : "chia init -c /root/.chia/ca" (if you copied the famer's ca directory as suggested above, adjust if needed) - restart the harvester : "chia start harvester" - check both logs (container and farmer nodes), you will see successful connections between both nodes if your logs are set at INFO level - if everything is fine, delete the adddata/chia/ca directory so that you don't have multiple copies of your keys around your network as a safety measure

Hi, Thanks for the template, I was waiting for it because my full node is on a Raspberry Pi4 and everything works fine, but harvesting from the Pi on an Unraid Samba share was just awful from a performance standpoint, especially while a new plot was being copied to the array (I saw response times beyond 30 seconds!). Now I run only a harvester in the container, and response times are more in the milliseconds range ! By tweaking config.yaml it's easy to connect the container harvester to the full node, after having generated keys for the harvester with chia init -c /path/to/full/node/certs (see https://github.com/Chia-Network/chia-blockchain/wiki/Farming-on-many-machines for more details). I just have a silly issue, the container seems to default to a generic "Europe" timezone, and timestamps are off by two hours with my local time in France. I added a "TZ" variable set to "Europe/Paris" to the template, but that changed nothing. I installed tzdata inside the container and dkpg-reconfigure tzdata to Europe/Paris, it's fine now, but obviously it's not a persistent solution. I would really prefer to have consistent timestamps in logs between the various machines (harvester container, full node, plotting machines). Thanks in advance for any guidance. PS : of course, my Unraid host is in my timezone

Hi, I have exactly the same issue as @kyis and will try to elaborate a bit further. I live in a area in France where ADSL connections are awfully slow (5Mbps DL / 0.7Mbps UL). So I have a 4G router (in bridge mode) with an external antenna as the main internet connection with very decent speeds (150Mbps DL/45Mbps UP), the ADSL ISP box is only used as a failover. An internal router manages the failover and routing for all internal devices. The issue is that port forwarding is not available on the 4G connection, as often. The workaround I've found is to have a Wireguard tunnel over the 4G connection with a VPN provider which accepts port forwarding on a limited number of ports. That works great and I can have access to my LAN from outside without any problem, except for the Remote Access by Unraid. I understand you get the IP used to contact your mothership server, in may case the public 4G address, which is not accessible from outside. Of course I could, as you suggest, implement policy-based-routing rules to force route the outgoing traffic from my Unraid server : - through the ADSL connection, but then the speeds would be awful, and the remote access would be practically unusable, although available - through the Wireguard tunnel, but then I would route all the traffic of the Unraid server through the VPN provider, and most of it (e.g. docker and plugin updates) doesn't really "deserve" it. The best solution, imho, would be to have a setting in the plugin to indicate a fully qualified name (or a fixed public IP) for the remote access entry point, in specific cases like @kyis or me. Otherwise, the workaround would be to get a detailed view on the exchanges between the Unraid server and your server(s) so that I can try and implement a reasonable routing policy, limiting the use of the WG tunnel to the communication between the plugin and your server(s). Thanks in advance for your attention.

@i-B4se, according to http://apcupsd.org/manual/manual.html#connecting-apcupsd-to-a-snmp-ups , you may try to populate the "Device" setting with "IPAddr:161:APC", in case the autodetection of the "vendor" qualifier fails with our UPS. Another option seems to switch from SNMP to PCNET protocol, see http://apcupsd.org/manual/manual.html#powerchute-network-shutdown-driver-pcnet , if your UPS/Network management card support it. But it's pure guess, I have no practical experience with Network Card / SNMP APC UPSes. Good luck, from my painful personal experience, getting apcupsd to work properly with an APC UPS with USB connection can be a long story ...

Thanks @ich777, quick and efficient, as usual ! I have a strong preference in Production branch rather than the New Features one on my server ...

Hi @ich777, I've seen the latest New Feature Branch driver 465.24.02 is now available in the settings page. Could you also make the latest Production Branch driver 460.73.01 available please ? The download page for this one also indicates "File Size: Temporarily unavailable", but the download link is fine, I just downloaded and installed it on another machine. Thanks for the great job, as usual 😉

Thanks for the reply, as usual 😉 Strange that I got such a slow DL speed from France (ISP Free). As I've said, I didn't have this issue when downloading v460.56 a few days ago. I understand your advice to avoid this possible problem during the reboot would be, when a new Nvidia linux driver is published, to : - download the latest driver package from the plugin page - set the driver version to this downloaded version rather than "latest" in the plugin page - reboot (without downloading, as the latest driver is already there) If that's correct, I'm fine with such a method, it gives more control on the driver version. Anyway Nvidia doesn't publish drivers every other day, and I'm not always willing to install them on day one ! Thanks again.

Hi all and @ich777, I upgraded a few days ago to 6.9.1 and also to the latest version of this great plugin without any issue. On first reboot it upgraded the nvidia drivers to 460.56, and the download at boot was reasonably fast afair. I'm currently rebooting the NAS for another reason (rsyslogd fix with this version), and as I've set the plugin to "latest" driver, it's currently downloading the 460.67 drivers (118 MB), which is the expected behavior. My issue is the download on boot is done at a ridiculously slow speed, around 100KB/s average, that is around 17 minutes for the full download ! As a consequence, the boot and outage time is significantly longer than expected. Just to understand, where is the package downloaded from ? I think @limetech, who are now supporting this plugin as part of the official Unraid setup, should provide a decent download repo with download speeds similar to what we get when updating the OS (AWS iirc). Thanks in advance for your thoughts and support.

I've updated the container 30 minutes ago, the app is now 8.6.0.1059, thanks for the support @Djoss! It has started a full block synchronization, 3% so far for a 1.4TB dataset

I have activated 2FA a few weeks ago, without any impact on the backup process in the container, and I've been under Unraid 6.9.0 beta35 for around 4 months, so no OS version change here. I just had a closer look at the backup history, it fails to update to the latest version, which is normal, and retries every hour, but backups are indeed working. The files modified today can be restored from the cloud, either from the container or the webadmin interface. So, I think the alert mail we have received with @TexasDave is more about the update fails than backup fails. As a reminder, the number of days after which you receive a warning email is a parameter which can be set in the webadmin interface. It's 2 days for me, but I think I have shortened it from 7 days to 2 days when I installed the container. That may explain why others haven't received -yet- these emails.

Exactly the same situation here, I think an update of the container is required with the latest version of CrashPlan.

No need to use an incognito window for me, but I rarely use it anyway. I prefer FAHControl which gives you much more control and features. Maybe you can try and empty your browser cache ?

Hello, During the night, the container has been automatically updated from 7.6.21-ls25 to 7.6.21-ls26. Since then, the existing GPU slot is disabled with the following message in the log : 08:22:15:WARNING:FS01:No CUDA or OpenCL 1.2+ support detected for GPU slot 01: gpu:43:0 GP106GL [Quadro P2000] [MED-XN71] 3935. Disabling. The server has been folding for at least 10 days, nothing else has changed in the setup (Unraid 6.9.0-beta35 with Nvidia Driver). Output of nvidia-smi : Sat Jan 9 09:26:32 2021 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 455.45.01 Driver Version: 455.45.01 CUDA Version: 11.1 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |===============================+======================+======================| | 0 Quadro P2000 Off | 00000000:2B:00.0 Off | N/A | | 64% 35C P0 16W / 75W | 0MiB / 5059MiB | 0% Default | | | | N/A | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+ So, I think this release has an issue, probably far beyond my technical skills ... Does anybody know how, as a workaround before a fix, I could downgrade from 7.6.21-ls26 to 7.6.21-ls25 which was perfectly fine ? Thanks in advance for the support. Edit : I got support on linuxserver.io discord channel, problem temporarily solved. Thanks again ! The container has been updated with new nvidia binaries, and it seems it is no longer compatible with my installed drivers (455.45.01). I don't know if it would be OK with the regular drivers proposed by Nvidia Driver plugin, ie 455.38 in 6.9.0-beta35. For sure, the best solution would be to have the latest stable Nvidia drivers (v460.32.03) in Unraid, as the latest version of the container is fully compatible with them. The workaround to downgrade to the previous version of the container is to edit the template repository from "linuxserver/foldingathome" to "linuxserver/foldingathome:7.6.21-ls25". Folding again, which is the most important for the moment ! But this example clearly raises the problem of regular updates of Nvidia drivers by Limetech when 6.9.0 is stable ... Until then, I'll stick to ls25 version of the container. Edit 2 : As I had posted an issue on github, the developers proposed me to test a dev build. I did and it worked fine, so I suppose a new version of the container will be soon publicly available and others should not have the same issue. Thanks for the responsiveness to @aptalca and linuxserver team !

Sorry, I've upgraded the firmware when the UPS arrived, but I used a Windows laptop directly connected to the UPS to do so. I never tried to use the firmware upgrade tool from a Windows VM in Unraid with the UPS passed through. It may work, but you'll have to test yourself. And I'm not aware of any linux CLI option to upgrade the firmware, as the APC tool is Windows only iirc. I take the opportunity of your APC UPS-related question to bump this thread as the situation is still the same for me in 6.9-beta 35. Who knows, a Christmas or @limetech miracle may happen, even if it's a bit late 😉

Hi, Well, the backup process has been running continuously for 4 days and a half, so I can step back a bit more now. The data to be backed up is 952 GB locally, 891 GB have been completed, and the remaining 61 GB should be uploaded in 11 hours from now. So, the global "performance" should be 952 GB in 127 hours, an average of 180 GB per day. Roughly, that is 2.1 MB/s or 17 Mbps, which is consistent with the obvious throttling I can see in Grafana for the CrashPlan container upload speed. Data is compressed before being uploaded, so translating the size of the data to backup into network upload size is not totally accurate, but the level of compression will highly depend on the data you back up. For me, 893 GB backed up so far translated into 787 GB uploaded, i.e. a compression ratio of 88%. To sum up, if you get the same upload speed and compression ratio as me, your initial 12TB backup should generate 10.8 TB (10,830 GB) to upload at an average speed of 180 GB per day, i.e. circa 60 days ... Btw, as the upload speed of your internet connection seems to be 20/25 Mbps, the best you can expect to upload this amount of data is circa 40/50 days. So, you wouldn't be that throttled. For the 10GB per day you heard of, I suppose that's what you found in the CrashPlan FAQ. Let's say it's somehow their commitment, even if it's not legally binding, so they take very very little risk not to fulfill it, it's circa 1 Mbps ... As for the system resources, the container has an avg CPU load of 9% (Ryzen 7 3700X CPU), avg 1.2 GB memory load (out of 32 GB), and a constant Array I/O read of 2 MB/s. So, you can see it's running, but it has a low footprint on the global server load. I hope that can help you decide on your backup strategy.

I've just installed the container and activated the 30-days trial. First, not the faintest issue to set up, very easy to install, I just set "Maximum memory" to 4096M to avoid crashes due to low memory. As for the upload bandwidth, my feelings are mixed so far. I have 2.5 TB to backup, and started the process on Sunday. Until Sunday 11pm (all times CET), the throughput was 16 Mbps (or 2MB/s). And then, it was between 32 and 40 Mbps all Dec. 21st long, which is the practical limit for my 4G internet connection. Great ! I then added other shares to the backup set, and since Dec 22nd, the average is back to 15/16 Mbps. So, somehow, we are throttled when backing up, that's obvious. They admit it between the lines on their FAQ, stating we are not individually throttled, but as the server-side bandwidth is shared, there are limitations. If it's true, they don't have enough bandwidth to supply a decent service. But I have a doubt, as the upload is obviously capped at 16Mbps most of the time for me, which should not be the case all day long, unless the server-side bandwidth is ridiculously undersized. Personally, I let the initial backup finish (4/5 days, less if I get decent speeds again), and I will see if the service is viable on a day-to-day basis. But I must admit I share your doubts ...

Thanks for your reply, as usual. I'll try to boot Unraid in GUI mode tomorrow, it's late in here. What I want to do with nvidia-settings is overclock the GPU, while undervolting it (with 'nvidia-smi -pl XXX' which works) to diminish the power draw and maintain the folding throughput. nvidia-settings works in command mode, and you can do the same as in GUI mode, esp. apply an offset to your clocks, i.e. overclock, provided you have the famous "Coolbits" set to 28 in xorg.conf. The main issue is nvidia-settings needs to run in an X server. Just to be sure, I have an integrated GPU on the IPMI motherboard (which is used by Unraid and is the primary graphics in BIOS), and the 3060 Ti with no screen attached just computing/transcoding. If I get it well, I should attach a monitor to the 3060Ti, change the primary graphics card in BIOS, and boot Unraid in GUI mode. We'll see ... I don't know what graphical environment Unraid uses when in GUI mode, and thus don't know how to tweak xorg.conf, if it exists. I had thought of another approach, using a container like your "debian-buster-nvidia", which on paper has everything I would need : the driver is installed, the graphical environment exists, so nvidia-settings should work from inside the container, either in cli or graphical mode. And the tweaks applied from there would maybe have an effect on the card itself, and thus on processes launched by another container. But it's mostly speculation at that stage, and very likely wishful thinking 😉 I've found many over-complicated and unsure approaches around when it comes to overclocking an Nvidia GPU on a headless server not running an X server. The best I've found so far is https://gist.github.com/johnstcn/add029045db93e0628ad15434203d13c#overclocking (in the context of coin mining, but folding has the same requirements if not objectives...). But as we can't install much nor persist settings across reboots in Unraid, I quickly reach a dead-end on my side 🙁

Hello, As already reported, I've successfully setup a RTX 3060Ti FE with this plugin and above all the help of @ich777, and it's properly used in 3 containers (telegraf for GPU monitoring, Plex for hw transcoding and Folding@Home for folding 24/7). Now I'd like to go a bit further and optimize the power consumption vs folding ratio. I've read in numerous forums about folding that the way to go was to undervolt and overclock the GPU to get the same computing power with less power drawn. Helping medical research (against Covid-19 among others) when the server is idle is ofc great, but if I can limit my electricity bill with the same output, that's also fine 😉. Undervolting is not an issue, with the 'nvidia-smi --power-limit=XXX' I can set the power limit anywhere between 100W and 220W with this card, default being 200W. But of course, when I lower the power limit, the built-in algorithm lowers the GPU and memory clock frequencies accordingly, which produces less science (as they say in F@H forum). The only way I've found to overclock an Nvidia GPU under Linux command-line is through the nvidia-settings utility, which is built-in with the drivers, the commands to overclock being : nvidia-settings -a '[gpu:0]/GPUGraphicsMemoryOffset[3]=50' #offset of +50Mhz on GPU Clock nvidia-settings -a '[gpu:0]/GPUMemoryTransferRateOffset[3]=50' #offset of +50Mhz on Memory Clock The purpose is to compensate for the clock frequencies lowered by the power limit algorithm with a positive offset to get the same computing power with less power drawn. As always, the challenge is to find the sweet spot between power consumption, computing power and stability. But I've already reasonably overclocked CPUs and GPUs, and I'm patient, so this is not a problem. Unluckily I didn't reach so far, because issuing the nvidia-settings ... command produces the following error : root@NAS:~# nvidia-settings nvidia-settings: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory After checking, this nvidia-settings utility requires a X11 server on the machine. Moreover, the xorg.conf file must contain these clauses Option "AllowEmptyInitialConfiguration" "True" Option "Coolbits" "28" to have an access to the clock offsets through nvidia-settings. Of course I understand Unraid OS does not come with, and does not need btw, any graphical environment, and that's why the utility throws an error. And it's really a poor design choice by Nvidia to require a graphical environment to fine tune the GPU on a headless server under CLI. I think nvidia-settings is basically a graphical utility to tune the nvidia drivers which accepts CLI commands (see https://forums.developer.nvidia.com/t/overclock-gpu-at-lower-voltages/139326/2 for instance). Anyway that's the way it seems to be, unless I missed something... All that could work fine if I ran F@H in a Linux VM with the GPU passed-through, but I'd prefer not to lose GPU computing performance due to the virtualization overhead and above all I would lose the ability to use the GPU in containers, and thus the whole interest of this great plugin... So I raise the question to the community, as my technical skills enable me to understand the root cause of the dead-end, but sadly not to find a solution by myself 🙁 Thanks in advance for your ideas and feedback.

I suspected H.265 was the problem, and you understand it correctly. Your other mp4 containers very likely contain streams with Maxwell compatible codecs, i.e. not H.265. As a piece of information, second-hand Quadro P2000s are rather easy to find, don't cost arm and leg, and are powered only by the PCI-E slot (75W), no extra power cable. I don't know where you live, but here in France I recently bought one, brand new from an Dell workstation where it was immediately replaced by a more powerful GPU, for 200€.

Just to let everybody know and follow up on my previous posts, I managed with the precious help of @ich777 to get my brand new Nvidia RTX 3060 Ti to be recognized and fully operational under Unraid 6.9.0-beta35 with the Nvidia driver plugin. I was lucky enough to get one of very few Founders Edition cards available here in France. Now the GPU is bravely folding proteins to help research against covid-19, running circa 6 times faster than the P2000 I had so far, with a power draw of 190W vs 75W ! I wanted to share this success with the whole community, and let's push Unraid forward alltogether !

Hi @Whatupdays, mp4 and mkv files (among other formats) are nothing but containers for video and/or audio streams. What is key to know why such or such stream is hardware transcoded or not by your GPU is the codec of the video stream inside the container. Under Windows you can use a tool like MKVToolNix to know exactly what the codec of the video stream is in your mkv, mp4, avi, ogg, ... container file. Then we'll certainly be able to understand why the video stream is not hardware transcoded by Plex. Having a look at https://www.elpamsoft.com/?p=Plex-Hardware-Transcoding , I noticed that the GeForce GTX980 (Maxwell 2nd Gen architecture) does not support H.265, which may explain your issue. It's also software limited to 3 simultaneous sessions. As for Quadro P2000 (Pascal architecture, the next one), it does support H.265, and has no sessions limit. So yes, transcoding capabilities of a P2000 are way superior to GTX980 for a Plex server.

Thks for the quick reply ! I hadn't understood @limetechwas the driver provider, so my question was more for them, I think. And yes, I would really like to test the card, just to check whether it's DOA ot not, so I'm ready to try the "hack" you seem to propose.

Hello, Thanks for this great plugin, installation was a no-brainer and my old P2000 can be used to transcode (Plex) and compute (F@H) without any problem with recent Nvidia drivers 455.38. But, the geek I am is now the happy owner of a brand new RTX 3060ti, which was delivered today. And, as you certainly know, this GPU needs drivers v455.45.01 released on 2020/11/17 to be supported. Although I'm sure you've already guessed the question, is there any plan to make this version of the nvidia drivers rapidly available through the plugin, so that the card doesn't remain in its box for too long 😉? And more generally, how do you envisage the availability of the latest drivers in the future, especially after the launch of a new GPU and the unavoidable drivers' debugging to follow? Thanks in advance for your help. PS : I had a look at your other Kernel Helper/Builder plugin, which may be a solution to get the latest nvidia drivers installed (?), but I would then need some further guidance. I'm not a total noob, but not a Linux kernel builder expert at all !