mgutt

I depends. If you are using hardware encoding your cpu cores have enough power left for Unraid's SHFS overhead. But if your videos are transcoded through CPU, than it should help to reduce the total load, especially if multiple movies are transcoded. But it depends on how fast your CPUs is, how many cores it has and which cores are used by Plex and Unraid. Regarding the size: No problem. Plex transcodes only x MB parts of a movie even if it's 4K, while it's playing (open the transcode folder while a movie is transcoded and you can see these files). And if the transcode folder becomes out of space, Plex starts purging it.

Many people are doing this, me included: https://forums.unraid.net/topic/35878-plex-guide-to-moving-transcoding-to-ram/page/12/?tab=comments#comment-894460 Plex cleans the Ramdisk by its owns l the most people use 4GB. The impact is there because even this tweak bypasses Unraid's SHFS overhead. In addition you protect your SSD against wear out.

I found a tweak to speed up Plex meta crawls, thumbnail creation, search function etc: https://forums.unraid.net/topic/88999-unraid-tweaks-for-media-server-performance/?tab=comments#comment-898167 The impact depends on your CPU. Low powered CPUs will benefit more.

I found by accident another tweak: Direct disk access (Bypass Unraid SHFS) Usually you set your Plex docker paths as follows: /mnt/user/Sharename For example this path for your Movies /mnt/user/Movies and this path for your AppData Config Path (which contains the thumbnails, frequently updated database file, etc): /mnt/user/appdata/Plex-Media-Server But instead, you should use this as your Config Path: /mnt/cache/appdata/Plex-Media-Server By that you bypass unraid's overhead (SHFS) and write directly to the cache disk. Requirements 1.) Create a backup of your appdata folder! You use this tweak on your own risk! 2.) Before changing a path to Direct Disk Access you need to stop the container and wait for at least 1 minute or even better, execute this command to be sure that all data is written from the RAM to the drives: sync; echo 1 > /proc/sys/vm/drop_caches If you are changing the path of multiple containers, do this every time after you stopped the container, before changing the path! 3.) This works only if appdata is already located on your SSD which happens only if you used the cache modes "prefer" or "only": 4.) To be sure that your Plex files are only on your SSD, you must open "Shares" and Press "Compute" for your appdata share. It shows if your data is located only on the SSD or on SSD and Disk. If its on the Disk, too, you must stop the docker engine, execute the mover and recheck through "Compute", after the mover has finished its work. You can not change the path to Direct SSD Access as long files are scattered or you will probably loose data! 5.) And you should set a minimum free space in your Global Share Settings for your SSD cache: This setting is only valid for Shared Access Paths and ignored by the new Direct Access Path. This means it reserves up to 100GB for your Plex container, no matter how many other processes are writing files to your SSD. Whats the benefit? After setting the appdata config path to Direct Access, I had a tremendous speed gain while loading covers, using the search function, updating metadata etc. And its even higher if you have a low power CPU as SHFS produces a high load on single cores. Shouldn't I update all path to Direct Access? Maybe you now think about changing your movies path as well to allow Direct Disk Access. I don't recommend that because you would need to add multiple paths for your movies, tv shows, etc as they are usually spreaded across multiple disks like: /mnt/disk1/Movies /mnt/disk2/Movies /mnt/disk3/Movies ... And if you move movies from one disk to another or add new disks etc this probably cause errors inside of Plex. Furthermore this complicates moving to a different server if this maybe uses a different disk order or an smaller amount of bigger disks. In short: Leave the other Shared Access paths as they are. Does this tweak work for other Containers? Yes. It even works for VM and docker.img paths. But pay attention to the requirements (create backup, flush the linux write cache, check your file locations, etc) before applying the Direct Access path. And think about, if it could be more useful to stay with the Shared Access Path. The general rule is: If a Share uses multiple Disks, do not change this path to Direct Access.

You are right. I've tested it. And changing the config path to direct cache disk access, resulted in a tremendous speed gain for Plex!

At the moment I'm playing around with the vm.dirty_ratio setting and found something interesting. The first test was to benchmark my NVMe. For that I reduced the dirty pages ratio to 1 which means 1% of 63 GB free RAM = 630 MB space for dirty pages. This should help to get real benchmarks which are not influenced by the RAM. So I started my benchmark with dd as follows: sysctl vm.dirty_ratio=20 rm -r /mnt/cache/Music/Benchmark/* fstrim -v /mnt/cache sleep 60 for bs in 512 4k 16k 64k 128k 256k 512k 1M > do > echo ---- $bs: ---- > dd if=/dev/zero of=/mnt/cache/Music/Benchmark/10G_${bs}.bin bs=$bs iflag=count_bytes count=10G > done ---- 512: ---- 20971520+0 records in 20971520+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 29.0343 s, 370 MB/s ---- 4k: ---- 2621440+0 records in 2621440+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 5.41366 s, 2.0 GB/s ---- 16k: ---- 655360+0 records in 655360+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 4.31003 s, 2.5 GB/s ---- 64k: ---- 163840+0 records in 163840+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 4.11446 s, 2.6 GB/s ---- 128k: ---- 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 7.68483 s, 1.4 GB/s ---- 256k: ---- 40960+0 records in 40960+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 8.7388 s, 1.2 GB/s ---- 512k: ---- 20480+0 records in 20480+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 8.7285 s, 1.2 GB/s ---- 1M: ---- 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 8.66134 s, 1.2 GB/s I wonder that "16k" and "64k" are the only block sizes that allow writing to the SSD with full speed altough its 4K-aligned. I guess it is because a higher block size means writing to more flash cells at the same time. For example 16k writes to four 4K blocks and 64k writes to sixteen 4K blocks at the same time, but why does it become slower if the block size is even bigger? Than I reminded that my 970 Evo NVMe has an SLC cache of 42 GB and a full cache means a maximum writing speed of around 1.2 GByte/s. So I repeated the test without the smaller block sizes: sysctl vm.dirty_ratio=1 rm -r /mnt/cache/Music/Benchmark/* fstrim -v /mnt/cache sleep 60 for bs in 128k 256k 512k 1M 4M > do > echo ---- $bs: ---- > dd if=/dev/zero of=/mnt/cache/Music/Benchmark/10G_${bs}.bin bs=$bs iflag=count_bytes count=10G > done ---- 128k: ---- 81920+0 records in 81920+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 3.96074 s, 2.7 GB/s ---- 256k: ---- 40960+0 records in 40960+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 4.24214 s, 2.5 GB/s ---- 512k: ---- 20480+0 records in 20480+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 4.19673 s, 2.6 GB/s ---- 1M: ---- 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 4.17924 s, 2.6 GB/s ---- 4M: ---- 2560+0 records in 2560+0 records out 10737418240 bytes (11 GB, 10 GiB) copied, 8.35124 s, 1.3 GB/s Ok, theory is correct. But what happens if we fully disable the dirty_pages by setting it to "0" (I reduced the file size to 100M after it took ages): sysctl vm.dirty_ratio=0 rm -r /mnt/cache/Music/Benchmark/* fstrim -v /mnt/cache sleep 60 for bs in 512 4k 16k 64k 128k 256k 512k 1M do echo ---- $bs: ---- dd if=/dev/zero of=/mnt/cache/Music/Benchmark/100M_${bs}.bin bs=$bs iflag=count_bytes count=100M done ---- 512: ---- 204800+0 records in 204800+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 21.2512 s, 4.9 MB/s ---- 4k: ---- 25600+0 records in 25600+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 21.5886 s, 4.9 MB/s ---- 16k: ---- 6400+0 records in 6400+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 19.723 s, 5.3 MB/s ---- 64k: ---- 1600+0 records in 1600+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 21.3909 s, 4.9 MB/s ---- 128k: ---- 800+0 records in 800+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 21.1618 s, 5.0 MB/s ---- 256k: ---- 400+0 records in 400+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 16.1569 s, 6.5 MB/s ---- 512k: ---- 200+0 records in 200+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 20.0074 s, 5.2 MB/s ---- 1M: ---- 100+0 records in 100+0 records out 104857600 bytes (105 MB, 100 MiB) copied, 27.8239 s, 3.8 MB/s Wow, this looked really really bad. But is it only because of dd? I verified it by an usual upload through my client: Then I set dirty ratio to 1 while the transfer was still running: Conclusion: Its a really bad idea to set dirty pages to "0".

Das Case hat meiner Ansicht nach das selbe Problem wie das DS380. Der Festplattenkäfig hat kaum Löcher und die Platten sind dazu eng aneinander. Außerdem ist der Luftauslass an der Seite versetzt von der Position der HDD Lüfter. Für kleinere Builds könnte man sich auch noch das Supermicro SC721TQ-250B oder das U-NAS NSC-410 / NSC-810 anschauen. Bis dahin aber viel Erfolg mit dem NUC. Wird schon

Bereits ein Windows Desktop nutzt die Grafikbeschleunigung einer GPU bzw ohne GPU gibt es logischerweise kein Bild. In einer VM denkt Windows, dass es eine GPU gäbe, aber in Wirklickeit übernimmt dies die virtuelle GPU names QXL, Cirrus, etc und die wird durch die CPU berechnet. Es gibt bessere und schlechtere virtuelle Grafiktreiber. Nutzen kann man eigentlich alle, die Frage ist eher ob man diese CPU-Leistung zur Verfügung stellen möchte/kann. Daher meine Frage ob dauerhaft ein Client genutzt werden soll. Ist ja nicht der Fall, also geht es auch für kurze Sessions virtuell. Define R4/R5? Vermutlich das beste Gehäuse für einen NAS-Selbstbau. Mit Gehäusen wie dem Silverstone DS380 habe ich so meine Probleme, weil die Platten sehr eng aneinander liegen und der Airflow auch wegen der seitlichen Lüfter echt schlecht ist. Mein Lieblingsgehäuse für "kleinere" Projekte ist ein Bitfenix Phenom Mini-ITX das 5 Bays hat: Ich habe dies sogar gemoddet (2 Löcher gebohrt ^^) und einen zweiten Käfig verbaut, so dass es ein 8-Bay wurde: Mit einem Icy Dock MB994SK-1B könnte man auch noch 4 gut erreichbare SSDs verbauen (das Case hat bereits 5 Plätze für SSDs, aber nicht gut zu erreichen): Für den Remotezugang nutze ich übrigens eine Lubuntu VM mit Real VNC, da ich bei meinem Kumpel keinen Zugriff auf den Router erhalte.

Ich habe vor allem danach gefragt um herauszufinden, ob du eine VM als Client nutzen willst, der sich mit einer Grafikbeschleunigung durch eine dedizierte GPU deutlich besser bedienen lässt. Da Unraid sich die erste GPU genehmigt (vorzugsweise die iGPU) und Nvidia Grid aktuell noch nicht unterstützt wird (um eine Quadro GPU mit mehreren VMs zu nutzen), muss man wissen wie viele zusätztliche GPUs und damit PCIe Slots auf dem Mainboard notwendig werden. Eine Server VM bedient man ja selten Remote. Da kann man dann auch ohne GPU drauf. Eine kurzzeitige hohe Last auf der CPU und das bisschen Latenz / Ruckeln ist dann nicht schlimm, aber bei einem Client kann das evtl anders aussehen. Ich habe zB ein Offsite-Backup-NAS und wenn ich da per Real VNC drauf gehe, dann liegt die CPU Auslastung mangels dedizierter GPU bei 70%: Allerdings ist die CPU natürlich auch alles andere als potent. 1.) Also meinst du, du brauchst eine GPU für VM und wenn ja wie viele? Auch die Frage, ob du IPMI/BMC benötigst, also einen Remote-Zugriff auf den Server inkl Bedienungsmöglichkeit des BIOS. Hier gilt ist zu beachten, dass IPMI/BMC über Internet aus Sicherheitsgründen grundsätzlich nicht gemacht werden soll. Will man also Remote auf das BIOS des Servers, müsste man sich vor Ort erst mit einem Client PC verbinden und von da per IPMI mit dem Server. Ich bevorzuge Mainboards ohne IPMI und nutze vor Ort mein Surface mit OBS und HDMI Capture Stick als Monitor und eine Logitech K400 für die Bedienung. Der Vorteil ist, dass die Auswahl an Mainboards dadurch deutlich größer wird. Außerdem verbraucht der Server dann durchgehend 5 Watt weniger. 2.) Brauchst du IPMI/BMC? Beim Gehäuse wäre wichtig zu wissen ob Du oder der Nutzer in der Lage wäre über die HDD Seriennummer eine evtl defekte HDD im Gehäuse auch ohne LED auszumachen. Die Gehäuse mit Einschüben, besitzen ja in der Regel solche LEDs und defekte HDDs können dann "ausgeblinkt" werden. Ich mache es dagegen an Hand der Seriennummer und bewaffne mich mit einer Taschenlampe ^^ Ich bevorzuge nur werkzeuglose interne Festplattenkäfige. Der Vorteil ist, dass dies die Gehäuse-Auswahl deutlich steigert und auch preislich attraktiver wäre. 3.) Brauchst du ein Case mit Einschüben und LEDs? Keine der Komponenten ist preislich attraktiv. Die Komponenten unterliegen ja teilweise täglichen Schwankungen und wer weiß wie oft Krenn da die Preise anpasst. Und ja, wenn du Business willst, bekommst du auch Business-Festplatten angeboten. Übrigens ist der Microserver nicht mehr über den Shop auffindbar ^^ Meiner Ansicht nach würden WD Red Plus, WD Red Pro oder Seagate Ironwolf (Pro) genauso gut passen. WD Red gilt es wegen der SMR Thematik zu meiden. Günstig kommt man an WD Red Plus (mit voller Garantie) über die WD Duo Gehäuse, allerdings sind da garantiert nur dann WD Red Plus drin, wenn du mindestens die 16TB Version nimmst und die kosten im Angebot auch schon 350-400 € (für 2x 8TB). Soll heißen, durch die schiere Größe der Platten, sind die bereits deutlich teurer als die 2TB Ultrastar, aber 2TB kommen mir eh arg wenig vor. Falls das aber genügt, kann man die Plus ja auch einzeln kaufen. Ich selbst habe ausschließlich WD Ultrastar verbaut und die aus den WD D10 XBOX Gehäusen ausgebaut. Bei teilweise unter 15 € pro TB ist das einfach unschlagbar günstig für eine Enterprise Festplatte mit 7200 Umdrehungen. Und in Unraid machen schnellere Platten evtl Sinn, da der Direktzugriff ja durch die Einzelgeschwindigkeit limitiert ist. Hängt aber auch davon ab wie groß der SSD Cache ist und damit alles so gut abgefangen wird, dass man die HDDs eigentlich nur als Cold Backup verwendet.

Mach mal ein Benchmark mit CrystalDiskMark innerhalb der Windows Maschine. Schau dir mal das Video an, gerade wegen der IOMMU Gruppen:

#7 "More Ram" completely rewritten

Also die Frage ist eigentlich Server oder Synology + NUC? Synology + NUC Schauen wir uns mal diese Software an: https://www.datev.de/web/de/m/marktplatz/dataflor-business/ Ich kann hier keinen Punkt erkennen, der einen aktuellen i5 notwendig machen würde. Das sieht doch einfach nur nach einer Datenbank aus, die der Server verwaltet. Ich denke die Hardware-Voraussetzungen sind eigentlich gar nicht so hoch, sondern sie beziehen sich damit auch auf sehr alte i5. Denn bei dem Client soll mindestens Windows 7 vorhanden sein und "mind. ein Intel Core 2 Duo mit mind. 3,0 GHz (besser Intel i5)". Der Core 2 Duo ist aus 2008, Windows 7 aus 2009 und der erste i5 aus 2010. Ein i5 aus 2010 ist eine ganz andere Hausnummer als einer aus 2020. Ich würde daher behaupten, dass jeder Prozessor, der im PassMark Benchmark mind 5000 Punkte hat, mit dieser Software gut zurecht kommt, da das einem mittelstarken i5 aus dem Jahr 2012 entspricht (natürlich ohne Gewähr). Ich wüsste also nicht warum nicht ein "alter" NUC 8 mit i5-8259U (NUC8i5BEH2) mit seinen 8271 Punkten nicht genug Leistung mitbringen sollte. Auch im Single Thread Rating ist er mit über 2000 Punkten denke ich stark genug, falls die Anwendung es nicht so mit Multi-Threading hat. Was würd dieser NUC so mit RAM und SSD so kosten. Denke mal um die 500 €. 1.) Wäre das preislich vertretbar? Server Deinem Beitrag zu folge möchtest du eine Fertiglösung und nicht selbst schrauben. So ein TrueNAS Mini mit seiner kleinen Atom-CPUs ist für VMs ungeignet. Die einzige Fertiglösung, die was für 1-2 VMs taugt, wäre der Microserver MI106+ mit einem 6- oder 8-Kerner. Hier die Preisliste: Eventuell findest du das teuer. Der Grund für den hohen Preis ist, dass ab 6 Kernen eine ECC RAM Unterstützung bei Intel immer zu einem Xeon Prozessor führt und die sind deutlich teurer als ein i7/i9, die diesen nicht unterstützen. Aus dem Grund gibt es auch kein Fertigprodukt mit i7, weil in der Branche Server mit Non-ECC RAM unüblich sind. 2.) Wäre denn so ein fertiger Microserver mit Xeon - und wir sprechen hier von über 1000 € - denn im Budget? 3.) Reichen dir die 4-Bays? 4.) Außerdem wäre es jetzt interessant zu wissen warum "1-2 VMs". Was genau soll die zweite VM leisten? Laut deiner Beschreibung ging es ja nur um den Server für die GaLa Software. Der bräuchte nicht mal eine GPU, da er nur selten über die Oberfläche bedient wird. Andere VMs zB ein Windows Client, "müssen" dagegen eine GPU haben, denn sonst läuft alles über eine virtuelle GPU, also die CPU, und die Bedienung wäre alles andere als flüssig. P.S. Falls du doch selber schrauben möchtest, sind die Möglichkeiten das günstiger umzusetzen, natürlich größer und wir können dir dann sicher weitere Tipps geben.

Die GTX750 unterstützt vermutlich NVENC. Das ist ja das was FFMPEG verwendet um Videos von sagen wir VC1 in H264 zu wandeln. Aber die GT 710 und GT 1030 haben diese Schnittstelle nicht: https://en.wikipedia.org/wiki/Nvidia_NVENC#Fourth_generation,_Pascal_GP10x "The NVIDIA GT 1030 and the Mobile Quadro P500 are GP108 chips that don't support the NVENC encoder." Es geht also nicht mal um H265, sondern sie können es soweit ich das verstanden habe, einfach gar nicht?! Abspielen, also NVDEC geht, aber das alleine bringt ja nichts. Das würde nur in einer VM helfen um zB Videos in einem Browser zu schauen.

Ich habe ein wenig recherchiert und würde bei meiner Aussage bleiben. In den Plex und Emby Foren verteilt sich das geht/geht nicht auf 50:50 und dann noch zusätzlich eingeschränkt mit dem PCIe x1 kann ich mir nicht vorstellen, dass die halbwegs gut transcodiert.

Den Riser brauchst du nicht. Die Karte sollte auch so laufen (natürlich begrenzt auf x1, aber das ist ja egal). Es gibt von Zotac auch eine GT 710 mit x1 Anschluss, aber die brauchst du eigentlich nur, wenn dein PCIe Port rechts nicht "offen" ist, also einen Schlitz besitzt um größere Karten einzustecken. Hier die zwei Varianten: Es soll schon Leute gegeben haben, die das Messer angesetzt haben ^^ Wenn dein Board übrigens PCIe 3.0 Slots hat und du die GT 1030 nimmst, hast du bei 1x auch mehr Leistung, da der Durchsatz bei PCIe 2.0 nur 0,5 GB/s ist und bei 3.0 knapp 1 GB/s. Die GT 710 unterstützt nur PCIe 2.0. Beim Transcoding hilft allerdings keine der beiden Karten, denn die haben keine Hardware-Beschleunigung: https://developer.nvidia.com/video-encode-decode-gpu-support-matrix https://www.elpamsoft.com/?p=Plex-Hardware-Transcoding Wenn Du also auch was fürs Transcoding brauchst, solltest du die GT1050(Ti) oder Quadro P400/P600 nehmen.

Vielleicht holst du dir als primäre Karte für Unraid/Docker noch eine GT710 (28 nm / 30-40 € neu / 15-25 € gebraucht) oder eine GT1030 (14 nm = sparsamer / 60-70 €).

I found a nice write-up which settings are present and how they work. Now I don't really know what to test, because everyone is using this Cache. Maybe I fully disable it and compare the results with the already existing benchmarks. By that we can compare what happens if the cache is full or empty. P.S. I do not use the Tips and Tweaks Plugin anymore because it can set Network Adapter values that aren't supported, so the server looses internet connection and/or is completely offline. I had this multiple times and after uninstalling the Plugin it never happened again.

@jonathanm Sorry, this was a typo. I meant "/mnt/cache/appdata/Plex-Media-Server". So direct access to cache disk. This should reduce CPU load as well as Unraid's SHFS process is bypassed.

Und wenn der kleine Port geschlitzt ist, kann man da auch längere Karten reinstecken (so dass die Karte dann logischerweise über weniger Lanes läuft). EDIT: Und das ist auch so der Fall:

Eventuell hattest du einfach irgendeinen Wackelkontakt. Vom Prinzip sollten sich die Karten ja alle sonst nichts geben. Vielleicht gibt es ja gute Angebote beim Prime Day ^^ In Deutschland ist die Asus ja nach wie vor die günstigste Karte. Wobei.. ne die QNAP ^^

Ich würde das nehmen, was gerade am günstigsten ist. Ich habe zB bei Amazon Warehouse die QNAP QXG-10G1T für 85 € gekauft und bei Aliexpress die LR-LINK 6880BT mit diversen Coupons für 68 €. Bedenke aber, dass bei dem hohen Warenwert der Zoll kräftig zuschlagen könnte. Dann war es das mit dem Schnäppchen aus Ali Du hast jetzt diese Marke "FANMI" gefunden. In deren Shop scheint es im Gegensatz zu LR-Link's Shop keine Karte mit Aquantia/Marvell Controller zu geben. Die können ja nicht nur 10G, sondern auch 2.5G oder 5G. Ob man das braucht ist allerdings fraglich. Ich denke man nutzt dann eh nur 10G. Interessant wäre zu wissen was eigentlich der Unterschied bei den Intel Controllern 82599, X550, usw ist. Auf der Intel Website habe ich das gefunden: X557-AT 3,4W TDP https://ark.intel.com/content/www/de/de/ark/products/series/82749/intel-ethernet-connection-x557-series.html X550-AT 8W TDP (die X550-T1 Karte mit diesem Controller soll laut Datenblatt max 8.4W verbrauchen) https://ark.intel.com/content/www/de/de/ark/products/series/75020/intel-ethernet-controller-x550-series.html 82599 7,1W TDP (steht im Datenblatt auf Seite 988) https://ark.intel.com/content/www/de/de/ark/products/series/32609/intel-82599-10-gigabit-ethernet-controller.html (laut Die Aquantia Karten liegen bei 6W (selbst schon gemessen), wobei das der Wert ist, wenn die Karte im Slot steckt und eine aktive 10G Verbindung hat und nicht, wenn man 1 GB/s darüber überträgt. Keine Ahnung was die maximal zieht. Leider finde ich keine Netzwerkkarte mit dem Intel X557-AT Controller. Dieser Controller wird scheinbar nur auf Mainboards verbaut. SFP + RJ45 Modul geht auch, dürfte aber unter dem Strich teurer werden, da die Karte alleine bei 100 € aufwärts liegt. Nach meiner Recherche dürfte der Stromverbrauch so einer Kombination bei 6,5 bis 8W liegen. Kann man das nicht im BIOS einstellen was jeder Slot nutzen soll?

Does this also happen if the target path is "/mnt/cache/sharename" (so directly writing to the disk)? The idea would be to set Plex config path to "/mnt/cache/appdata/Plex-Media-Server" and configure a minimum free cache of "100GB" so Plex never starts writing to the array, no matter how full the cache disk is.

There is a downside by enabling Multichannel + RSS: Downloading from HDD Array without RSS: Downloading with RSS: We know that enabling RSS splits the SMB transfer across my 4 CPU cores in 4 different file streams, but I never excepted that those splitted streams read from different HDD sectors. I thought it will read one stream, split it by the CPU into the RAM and the send it to the downloading Client. But it is obviously not so. Note: Uploading to the HDD array has no impact with RSS. So enabling Multchannel with multiple NICs or enabling RSS with a single NIC has positive Impact on SSDs, but negative impact on downloading from HDDs. At least with Samba 4.11 as used by Unraid 6.8.3. Maybe this becomes better in further Samba versions. We will see. But there is more... I found a new step for the Guide: Installing huge RAM, boosts all Uploads and recurring Downloads. This happens after I wanted to show a friend how slow Unraid could be, if you write directly to the HDDs and yes these benchmarks were done without SSD Cache: Of course this could only happen because it writes to the Server's RAM instead to the HDDs, so I uploaded some really huge files and after around 15GB, the 1GB/s transfer fell down to 70 MB/s as expected: After interrupting the transfer it took several minutes until the dashboard didn't show anymore writes. This means the file transfer filled the Server's RAM and as the RAM is much faster than the HDDs, it needs additional time to finally move the file from the RAM to the HDD. So the Server's RAM works similar to an SLC-Cache of an SSD. Nice 😎 But why is this feature not part of the Unraid settings? I mean using an Unraid server without an USV is extremely risky as long files are not finally written to the array. And why does it "only" use 10-15GB of my RAM as writing cache, although there was much more usable? Did anyone heard about this writing cache before? Many benchmarks for nothing... As annoucend in #5 of this Guide I wanted to determine which Samba configurations could add some extra boost. And now, after 5 days of testing, I found this RAM Cache thing. This means all my benchmarks are "wrong" and need re-testing 😭 Ok, they are not really wrong, because they show the real performance of my server, but as not all users install so much RAM, we need test them with a smaller RAM-cache as well. Its time for a huuuuge RAM Disk to block caching 😁

Ich will ja jetzt nicht hetzen, aber ich hab' gelesen: ^^

@SelfSD https://www.reddit.com/r/PleX/comments/j0bzu1/it_was_working_before_but_now_im_having_issues/ "I solved the issue by uninstalling everything nvidia on my system and then manually installing the 450.66 drivers downloaded from nvidia’s website, then reinstalling nvidia-docker2."