Daniel15

The repo for the SR-IOV DKMS module itself (which is the core functionality of this plugin) is still maintained; it was last updated 3 days ago: https://github.com/strongtz/i915-sriov-dkms Last I heard, Intel were working on mainlining SR-IOV support, but they had to delay it due to higher priority kernel work. I haven't seen any recent updates though, so I'm not sure if they still plan to do it. Here's the thread: https://github.com/intel/linux-intel-lts/issues/33

@Lolight Silent corruption definitely has to do with ECC. With non-ECC RAM, data can get corrupted in memory before being written to disk, or corrupted when being transferred from the memory to the CPU. This is silent corruption because there's no way to tell that it happened, since a checksum written to disk (like what ZFS does for bitrot protection) will be a checksum of the corrupted data. For every byte (8 bits) of RAM, ECC can detect and automatically correct an error in one bit, and can detect (but not correct) an issue in two bits. It's very rare to have memory data corruption in more than a single bit per byte.

I've been trying a bunch of things but I'm still unable to reach any package C-states: C-states are enabled in the BIOS, and I even tried manually increasing the package C-state limit to C10: I'm using an i5-13500 and an Asus Pro WS W680M-ACE SE motherboard. I'm already running powertop --auto-tune on boot.

Your hardware looks good. Since you're getting this board, you may as well get ECC RAM. That RAM you're getting is not ECC RAM - note that "on die ECC" is not the same thing as regular ECC, even if some manufacturers try to advertise it as such. All DDR5 has on-die ECC, and its purpose is mostly to increase manufacturing yield. It doesn't give you the protection that regular ECC does. 2 x 32GB Kingston KSM48E40BD8KM-32HM or KSM48E40BD8KI-32HA doesn't cost much more than the Crucial RAM you picked, and it supports ECC. 850W PSU is overkill for a server, even with a CPU like the 14700K, unless you're planning on putting a high-end graphics card in it. PSUs are usually pretty inefficient if you're only using less than 20-25% of their capacity and using a smaller PSU will save you some money (both in the cost of the PSU, and the cost of electricity). I guess you may want to have a higher-power PSU in case you ever reuse it for something else in the future? I'm running my server on a 550W PSU because it's the smallest I can find, and even that is overkill (at least for me) since power draw at the wall for my system is always less than 150W. 400-450W is usually good for a server, but now that GPUs consume huge amounts of power, it's very difficult to find 'regular' PSUs that are that size, only server PSUs (which are small and have very loud fans since they're designed for 1U rackmount servers).

Sorry for the delay in replying. Settings are below: Are there other settings that affect the iGPU?

Not 100% sure, but from what I can tell, this commit is talking about physical video connections on the BMC itself. The Asus boards have a VGA connection that goes through the BMC. I'm one of the people still on 6.12.4 and the iGPU is working for me without a dummy plug attached. I'll try the upgrade to the latest Unraid version at some point. I did try upgrading to 6.12.6 a while back and the SR-IOV addin started causing kernel panics on boot so I had to revert.

For VictoriaMetrics, I'd update the 'overview' and 'additional requirements' to recommend using VictoriaMetrics with Home Assistant's Prometheus integration rather than its InfluxDB one. Prometheus has cleaner labels, is better supported in VMUI, and VictoriaMetrics uses PromQL-compatible queries so it's better to use data sources that were designed for that.

I do. I've got IPMI + iGPU + SR-IOV all working. I'm still on Unraid 6.12.4 though, and I've heard from other posts in this thread that it breaks if you upgrade to 6.12.6 or above. Maybe a kernel bug? Unraid is on a fairly old kernel series (6.1.x) so I might try booting a live CD of a different distro with a newer kernel and see if it has the same issue.

Which filesystem are you using?

Works for me. I'm still on Unraid 6.12.4 though, so I'm not sure if it broke in newer Unraid versions. I'm running Windows Server 2022 and am running Blue Iris with Intel video acceleration to record my security cameras. It doesn't use a lot of GPU power, but it's definitely using it: iGPU is configured as second graphics card, to allow VNC to still work properly:

I sometimes use it to watch the boot process (make sure nothing fails during Unraid startup) and the shutdown process (e.g. see if VMs are not shutting down cleanly or filesystems aren't unmounting cleanly), so losing it isn't ideal. I'll try dig into it when I have time, but it's hard for me to get enough free time to do that.

Ahh, interesting. I'm still on 6.12.4 because the SR-IOV plugin didn't support newer Unraid versions for a while. That's been fixed now, but I haven't had time to upgrade. I'd guess that some change in the Linux kernel between those two versions is causing the issue. 6.12.4 uses Linux kernel 6.1.49 whereas 6.12.6 uses Linux 6.1.64. I don't see many changes to the ASpeed `ast` driver in the 6.1.x kernel branch: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/gpu/drm/ast?h=linux-6.1.y. I do see some changes in November 2023 in the latest dev branch, at least in Linus' kernel repo: https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/ast. Those changes were for Linux 6.8 but I wonder if some of them have been backported into the kernel that Unraid uses. Of course, it could also be a change outside the ast driver that's causing the issues. Has anyone reported this as a kernel bug yet?

Technically there is a way to have bitrot protection on a single disk, but it halves the amount of disk space you can use. You can configure ZFS to store two copies on the same disk. That'd affect write speeds too, since each write actually does two writes. I don't know if anyone actually uses this feature for a whole disk on a production system though. Where it's more useful is if you create a separate dataset and set copies=2 just for that dataset (e.g. for your most important files)

Yeah - this depends a lot on your use case. For me, most of the files on my NAS aren't 'disposable' files like TV shows and movies - they're things like family photos, personal documents (taxes, mortgage paperwork, etc), backups of several other servers, email backups going back nearly 20 years, music that I've ripped from CD in the past and is very difficult to find these days, etc. I also don't have many drives. For my use case, ZFS' bitrot protection is more important than drives powering down while idle. You need to use a ZFS pool to take advantage of its bitrot protection. The other option is to use an Unraid array of individual ZFS drives. This is similar to what you'd do for XFS drives today. It gives some of ZFS' advantages (like snapshots and compression), but doesn't provide its main benefits (like bitrot protection). This is described as the "hybrid approach" on this page: https://unraid.net/blog/zfs-guide

You could try limiting the power draw too (reduce the maximum wattage). I just saw this article this morning: https://www.tomshardware.com/pc-components/cpus/is-your-intel-core-i9-13900k-crashing-in-games-your-motherboard-bios-settings-may-be-to-blame-other-high-end-intel-cpus-also-affected There's two settings in the BIOS for it: One for max power draw normally, and one for max power draw during turbo.