bytchslappa

You will need to aim a little higher than the GT1030 for hw encoding - it physically doesn't have NVEC encoders - it does have decoders for hardware accelerated decoding - aka video playback - but thats it.

Simple spelling mistakes always concern me....

So i noticed this in my logs after the script that executes "nvidia-smi -pm 1" to enable Persistence mode to force the P8 power state. "kernel: NVRM: Persistence mode is deprecated and will be removed in a future release. Please use nvidia-persistenced instead." So looked into it, so instead of using the nvidia-smi command to perform the job - now use the command nvidia-persistenced. Docs for it can be found here: https://download.nvidia.com/XFree86/Linux-x86_64/396.51/README/nvidia-persistenced.html Using just the nvidia-persistenced command by itself with no argument should be enough for most setups.

If your are running 6.7.x you could be hitting an issue a number of us have experienced. When writing to the array, performance of docker, VMs, other writes goes down to the point they stop responding.. Rolling back to 6.6.7 gets everything working again..

I'm trying 6.6.7 and there are no issues like the above.. I couldn't even install or update a docker image - let alone goto the docker page in the GUI while copying data via SMB or the mover running... 6.6.7 i can happily do that - and have plex running as it should. So whats broken in 6.7.x...

Any data access to the array causes all docker and VM activity to become unresponsive. Copying a file via SMB or moving data from cache manually causes docker to become unresponsive - this isn't just during mover activities. Lets say copying a file to the array via SMB to a share that is not part of the cache pool. copying a single file is causing the docker and/or vm's to become unresponsive - this might happen after maybe 500mb into the file. I've tried different parity drives(SATA and SAS drives), different controllers(SAS and SATA), different setups of the SATA controller, different network cards.

Same...

No - I guess the main issue I am having - and when the movers runs - copying a file to the array via SMB will bring all dockers to a halt - not just the mover.. even with the docker file running on the cache drive...this is writing directly to the array and not to the cache drive.

Diags attached for the current config.. it was suggested in another forum that i move all appdata and docker image to the cache drive.. still no dice.. unraidtest-diagnostics-20190725-2343.zip

I am testing unraid as a replacement for my windows server for plex and all the bits that go with it. Having a similair issue where the mover will kill plex - or all docker content - will try the plugin mentioned here to reduce the priority - but also copying data to a share also brings docker containers to a standstill. Ive tried multiple configs with SSD caches etc, locking the appdata to SSD etc - and no luck in improving performance. The current windows server runs a mix of hardware raid for some disks - and flexraid for the rest - flexraid is now pretty much dead as for upgrades and support - but certainly doesn't suffer from what I am seeing here - neither did freenas on the same hardware.