June 16, 20197 yr I need help deciding between two setups. Setup 1: i9 9900k 32 gb non-ecc ram Setup 2: threadripper 1920x 32gb ecc ram 1060 gpu Primarily, I want to optimize for unraid, plex transcoding (and conversion for sync), and being able to dedicate 2-4 threads to a Roon VM. Pros of setup 1: significantly lower power consumption (currently testing out the threadripper and it idles around 150-160w, while the 8700k I'm also testing idles around 70-80w) better performance at conversion for sync , presumably transcoding (8700k I'm testing converts a 1080p movie to 720p about 17% faster, so I assume the 9900k would be even faster) much easier software configuration for plex hardware acceleration Pros of setup 2: ECC ram - which I've had in my build for the last 5 years but I'm not sure how much it 'saved' me 8 more threads (4 more cores), so dedicating 2-4 of them for Roon won't affect the rest of system too much potentially better transcoding/conversion performance in future as support for offloading to GPU improves more PCIE lanes means full 3GB/s throughput of my NVME drives (which are bottlenecked at 2.5GB/s with the 8700k I'm testing) What would you all do? Edited June 17, 20197 yr by notphilip
June 16, 20197 yr 17 minutes ago, notphilip said: better performance at conversion for sync , presumably transcoding (8700k I'm testing converts a 1080p movie to 720p about 17% faster, so I assume the 9900k would be even faster) If you want to do hardware transcoding with Plex leveraging the iGPU in the 9900K, be aware that the i915 drivers in the Linux 4,19.xx kernel in unRAID 6.7.0 do not support the 9 series Intel chips. Of course, you could always install a discrete nVidia GPU and use the LSIO nVidia unRAID plugin, but, you cannot currently utilize the 9900K iGPU. Supposedly, support for the iGPU in the 9900K requires Linux kernel version 4.20 or greater. Software transcoding is a different issue as that is all CPU and the more/faster CPUs you throw at it the more you can do.
June 17, 20197 yr Author 1 hour ago, Hoopster said: If you want to do hardware transcoding with Plex leveraging the iGPU in the 9900K, be aware that the i915 drivers in the Linux 4,19.xx kernel in unRAID 6.7.0 do not support the 9 series Intel chips. Of course, you could always install a discrete nVidia GPU and use the LSIO nVidia unRAID plugin, but, you cannot currently utilize the 9900K iGPU. Supposedly, support for the iGPU in the 9900K requires Linux kernel version 4.20 or greater. Software transcoding is a different issue as that is all CPU and the more/faster CPUs you throw at it the more you can do. Interesting. But presumably, the unraid kernel will update over time and will eventually get support for the 9900k iGPU?
June 17, 20197 yr Interesting. But presumably, the unraid kernel will update over time and will eventually get support for the 9900k iGPU?Yes. It is just a current limitation until such time as unRAID implements a newer Linux kernel.Sent from my iPhone using Tapatalk
June 17, 20197 yr 11 hours ago, Hoopster said: Yes. It is just a current limitation until such time as unRAID implements a newer Linux kernel. Sent from my iPhone using Tapatalk I believe it was said previously on here that the next UnRAID version (6.8) will have a kernel well past 4.20 (in the 5.0 range).
June 17, 20197 yr What about the non-ECC ram?I am thinking of exactly the same setup, although to have a headless VM desktop for lightroom and gaming. Sent from my SM-G973F using Tapatalk
June 17, 20197 yr Author 13 minutes ago, dheg said: What about the non-ECC ram? I am thinking of exactly the same setup, although to have a headless VM desktop for lightroom and gaming. Sent from my SM-G973F using Tapatalk That's my big question. How important is ECC ram, particularly if my array is formatted as reiserfs? I've had ECC in my old rig for the last five years, and no data corruption failures happened - but was that due to the RAM or the general reliability of my drives? I can't tell if it was worth the cost and compatibility hassle of finding ECC ram. If ECC ram doesn't matter much, then I'm probably better off with the 9900k option. If it does matter, then I'm better off with the 1920x. Right now, I'm feeling a bit conservative, so I'm leaning towards the 1920x for ECC ram, and the hope that one day, GPU offloading in plex will be sufficiently good that a 1060/1920x will vastly outperform the 9900k. I also have the option to get more RAM and NVME drives with the 1920x, while the 9900k is maxed out at 2 nvmes and 4 sticks of RAM.
June 17, 20197 yr 22 minutes ago, notphilip said: How important is ECC ram, particularly if my array is formatted as reiserfs? I've had ECC in my old rig for the last five years, and no data corruption failures happened - but was that due to the RAM or the general reliability of my drives? I can't tell if it was worth the cost and compatibility hassle of finding ECC ram. If ECC ram doesn't matter much, then I'm probably better off with the 9900k option. If it does matter, then I'm better off with the 1920x. There are varying opinions in these forums regarding the necessity for ECC RAM. My main server is on 24x7 and I opted for server-grade hardware. I use a Xeon processor which, of course, supports ECC RAM. Given my configuration it just makes sense to use ECC RAM. My backup server uses an i5-4590 and has non-ECC RAM, however, it is only on occasionally. I have been using unRAID for almost 8 years. The first four years was with more consumer-grade hardware and non-ECC RAM. The last 3+ years I have used ECC RAM in my main server. In both cases, I have never had an error or data corruption that could be attributed to RAM problems. Actually, to my knowledge, I have never had any kind of data corruption (knock on wood). In your case, perhaps ECC RAM support or lack thereof should not be the deciding factor in your hardware choice. My MB and CPU choices recently have all supported ECC RAM so I use it. Other previous choices did not. FYI - you should format your array drives in XFS (BTRFS if you prefer) and not Reiserfs. There is no ongoing support for Reiserfs and XFS is now the default file system choice in unRAID. Edited June 17, 20197 yr by Hoopster
June 17, 20197 yr Author 2 minutes ago, Hoopster said: There are varying opinions in these forums regarding the necessity for ECC RAM. My main server is on 24x7 and I opted for server-grade hardware. I use a Xeon processor which, of course, supports ECC RAM. Given my configuration it just makes sense to use ECC RAM. My backup server uses an i5-4590 and has non-ECC RAM, however, it is only on occasionally. I have been using unRAID for almost 8 years. The first four years was with more consumer-grade hardware and non-ECC RAM. The last 3+ years I have used ECC RAM in my main server. In both cases, I have never had an error or data corruption that could be attributed to RAM problems. Actually, to my knowledge, I have never had any kind of data corruption (knock on wood). In your case, perhaps ECC RAM support or lack thereof should not be the deciding factor in your hardware choice. My MB and CPU choices recently have all supported ECC RAM so I use it. Other previous choices did not. FYI - you should format your array drives in XFS (BTRFS if you prefer) and not Reiserfs. There is no ongoing support for Resierfs and XFS is now the default file system choice in unRAID. Interesting. That's a good idea. Is there a guide to formatting drives that are actively in use? For context, I have 5 3tb data drives with about 5tb currently used across all of them. So should I move all the data to two drives, format three of them, then move the data to those three drives, and format the remaining two? Is there any guide or easy way to do this? (I imagine the unbalance plugin is in the answer, but I'm not terribly familiar with how it works)
June 17, 20197 yr 5 minutes ago, notphilip said: That's a good idea. Is there a guide to formatting drives that are actively in use? I followed this guide a couple of years ago to convert my Reiserfs drives one at a time to XFS. Worked flawlessly.
Archived
This topic is now archived and is closed to further replies.