BRiT

This was 4 years ago. People didn't know any better back then.

It does look like it's in an 8x Slot. Well your system does seem a bit of a mystery as to why your Parity Check speeds are limited, unless it's truly limited by the speed of the smaller capacity drives. So the thought was no harm trying to switch to the other slot and see if it impact benchmarks at all. If it's put into a lesser capable slot, then the impacts should be shown immediately, but there's a slight chance it might be put into a more capable slot or at least one that might behave differently. It's more of a this doesn't make much sense, so try something idea.

If it isn't an issue, any chance you can switch PCIExpress ports for the controller? Just to rule out any inaccuracies in the motherboard manual on which port is wired to which?

Replace your slowest drives?

Do yourself a huge favor and don't ever put your unraid server directly on the internet.

A bump does nothing. What needs to be done is what BonieNL already said, post this in Feature Requests.

I only received the final notification when using Block. It sounds like its perhaps temperamental on your system?

All my drives are shingled (8TB Seagates) yet I'm in the 182 MB/s range. Your bottleneck is something else.

For completeness, I ran a Long test with 4.1 Beta 2. LongSyncTestReport_2019_08_12_1735.txt

You would have to install / update the actual docker container with that version of 7Zip since all post download scripts in nzbget run inside of its docker container, and not in the unRaid host context.

Result from run with dockers turned off. The test results has better consistency. --- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 10min Duration)--- Tst | RAM | stri | win | req | thresh | MB/s ---------------------------------------------- 1 | 152 | 6912 | 3456 | 128 | 3392 | 181.7 The Fastest settings tested give a peak speed of 182.2 MB/s md_sync_window: 9216 md_num_stripes: 18432 md_sync_thresh: 9215 nr_requests: 128 This will consume 406 MB (254 MB more than your current utilization of 152 MB) The Thriftiest settings (95% of Fastest) give a peak speed of 179.4 MB/s md_sync_window: 192 md_num_stripes: 384 md_sync_thresh: 184 nr_requests: 128 This will consume 8 MB (144 MB less than your current utilization of 152 MB) The Recommended settings (99% of Fastest) give a peak speed of 180.8 MB/s md_sync_window: 256 md_num_stripes: 512 md_sync_thresh: 248 nr_requests: 128 This will consume 11 MB (141 MB less than your current utilization of 152 MB) NOTE: Adding additional drives will increase memory consumption. In Unraid, go to Settings > Disk Settings to set your chosen parameter values. Completed: 17 Hrs 44 Min 58 Sec. LongSyncTestReport_2019_08_10_2343.txt

Was it set to that when you started it up for the very first time? With some docker containers, the devs have it setup so the user/group only happens on the very initial setup. I run LSIO's container and their default template seemed to use UID 2 and GID 2 which maps to daemon/daemon.

I think ... You need to set proper UID and GID on the Emby container when setting up the Docker for the first time so it doesn't use daemon / daemon and instead uses nobody / users.

Yeah, I made sure cachedirs was disabled but forgot to disable Emby that does some hourly scans of the libraries. So it's likely the result of that. I had no downloads or uploads going on with no VMs running and no other server activity. As to using low numbers, I try not to if only because of memories from issues way back in the 4.x days with reads or writes being starved out, and I have oodles of memory to spare where 150 meg isn't a concern. Even though I know everything is setup differently now and those issues shouldn't ever happen with the new software design. For curiosity sake I started a full parity check before the last post to see how it plays out over the long haul. When the parity check finishes and when I can turn off Emby and all dockers, I'll run another Tuner script round trying for more consistency.

Here's the logs from my run. I opted to adjust my settings based on these settings from Pass 2 instead of any of the resulting findings. --- TEST PASS 2 (10 Hrs - 49 Sample Points @ 10min Duration) --- Tst | RAM | stri | win | req | thresh | MB/s 31 | 152 | 6912 | 3456 | 128 | 3392 | 181.7 --- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 10min Duration)--- Tst | RAM | stri | win | req | thresh | MB/s ---------------------------------------------- 1 | 180 | 8192 | 3686 | 128 | 1843 | 177.7 --- BASELINE TEST OF UNRAID DEFAULT VALUES (1 Sample Point @ 10min Duration)--- Tst | RAM | stri | win | req | thresh | MB/s ---------------------------------------------- 1 | 28 | 1280 | 384 | 128 | 192 | 177.5 The results below do NOT include the Baseline test of current values. The Fastest settings tested give a peak speed of 181.8 MB/s md_sync_window: 4544 md_num_stripes: 9088 md_sync_thresh: 4488 nr_requests: 128 This will consume 200 MB (20 MB more than your current utilization of 180 MB) The Thriftiest settings (95% of Fastest) give a peak speed of 173.6 MB/s md_sync_window: 384 md_num_stripes: 768 md_sync_thresh: 192 nr_requests: 128 This will consume 16 MB (164 MB less than your current utilization of 180 MB) The Recommended settings (99% of Fastest) give a peak speed of 180.3 MB/s md_sync_window: 768 md_num_stripes: 1536 md_sync_thresh: 760 nr_requests: 128 This will consume 33 MB (147 MB less than your current utilization of 180 MB) LongSyncTestReport_2019_08_09_1119.txt