darckhart

Is there a way (in some setting maybe) to make sure this plugin obeys the same update check procedure as other Unraid Plugins? ie, when I want to check updates for all my plugins, I go to the very top menubar and click Plugins, then the Check for Updates button at the top right. But UD appears to decide to check for updates itself outside of this. And then it adds this notification banner on the main Dashboard. I only want this unraid box to go out to the internet when I explicitly tell it to. Am I missing a configuration somewhere? Thanks!

Thank you! When I clicked the docs link in the OP I scanned and didn't see a JF specific FAQ and didn't even think to check the general unraid one! I'll remember that for future!

I haven't updated since v10.7.2 and updated last night to v10.7.5 apparently. Unfortunately, JF has broken direct stream/direct play. Is there any way to rollback this container?

just an update: ran a parity check over this weekend. same issue (throughput is around 65 MB/s) even with the CPU MHz uncapped, mitigations off, and pstate set to performance. seems like downgrading may be the only option now.

Thanks. I'll give it a try this weekend. If method 1 works permanently, I guess that will be good since I won't have to downgrade.

Interesting link! Thanks so much for the find! I think it is making a difference. The first /proc/cpuinfo command shows me 480 MHz. After the second command and then check CPU again, it now shows one core boosted up to 2.2 GHz. (I'm doing a SHA2 hash.) I don't understand your last post though: "add that line to the go file." What is that and how do I do it? Also, in case I need to do it, how do I downgrade? I found instructions for how to go back to the previously used one (but for me that would be 6.9.0-b25) but I need to go further back. How is that done?

Thanks for both those advice. I will report back after trying the downgrade. (might be a while since I want to let the check complete.)

I was directed to this thread from one I started recently in General Support here. Lots of my config info, etc, are posted there. In brief, I have an Intel J3160 cpu with 16 GB ram with array of 6x 6TB 7200 rpm data drives with two parity (2x 6TB) - all the same model HGST Deskstars. I also have 2x Samsung 850 EVO 1 TB for cache pool. I have not changed any hardware since the beginning. I am also experiencing VERY DRASTIC SLOWDOWN. I can't tell when I upgraded to each newer version of UnraidOS but I am guessing from my Parity History that it parallels what other users here have seen. I started with 160 MB/s checking speed dropping to about 85 MB/s and now on 6.9.0-b30, I am seeing a paltry 23.5 MB/s. After testing with diskspeed, all disks and controllers report throughput 100-200 MB/s. I DO have a wimpy CPU also which, after reading all posts, sounds like it is the particular piece of hardware that is not taking it well. There are some outlier 'high throughput speed' entries on my parity check log, but I am attributing that to the way the log seems to calcuate since I pause my check during the day (too hot) and restart again at night. parity-history.txt

Yes, that is correct. There have been no hardware configuration changes. I have always had two parity. Thanks very much for pointing out that issue thread. I will add to it. I am a little worried about downgrading. Might it break compatibility with things?

Really appreciate your continued help troubleshooting this! Good to know it is not disk related. Your highlighting of CPU is interesting. However, I have NOT added nor changed any hardware since the beginning: same CPU, same drives and number of drives. Additionally, it is not a gradual decrease in throughput over time; it appears to be huge drops. See attached throughput history. In the beginning, it was blazing fast like 160 MB/s. Then somewhere along the way it dropped to 85 MB/s. (I believe the super high outlier rates are an artefact of how the table is generated. I don't think it takes into account that I pause the check, so when it resumes and there's a teeny bit left to check, it might appear way faster than it should be?) I am trying to guess (with no knowledge really about how all this works) what might be influencing throughput. 1. We seem to have concluded that it's not disk related nor controller related. However, when looking at the output of that terminal command, the speeds looked odd to me. They are all such similar numbers that it made me wonder if there was something acting to cap it. 2. Is it software related? ie, I thought maybe the linux kernel updates with mitigations for Intel might be a factor, but we checked that too and doesn't seem so. Has maybe Parity Check function itself changed in the UnraidOS updates? 3. I would think also that as the Parity drive fills up with Parity data, it would take longer to get through it all. However, that shouldn't influence throughput correct? parity-history.txt

Looks like Disabling Mitigation did not affect anything. I am still seeing checking throughput at about 23 MB/s. I attached two images. One is for Parity 1 and Disk 4, the other is Parity 2 and Disk 2. Controller throughput looks fine to me? Here is output of the terminal command. Seems like something is capping it? Average: DEV tps rkB/s wkB/s areq-sz aqu-sz await svctm %util Average: loop0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: loop1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: loop2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: loop3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: sdc 33.53 22534.29 0.00 672.00 1.06 31.66 2.93 9.83 Average: sdd 33.53 22534.29 0.00 672.00 1.03 30.58 2.28 7.65 Average: sde 33.49 22507.43 0.00 672.00 1.21 36.14 7.50 25.11 Average: sdf 33.49 22507.43 0.00 672.00 1.23 36.66 7.88 26.39 Average: sdg 33.49 22507.43 0.00 672.00 1.23 36.66 7.78 26.07 Average: sdh 33.49 22507.43 0.00 672.00 1.25 37.19 8.22 27.55 Average: sdi 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: sdk 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: sdj 33.53 22534.29 0.00 672.00 1.11 33.11 4.59 15.41 Average: sdl 33.49 22507.43 0.00 672.00 1.13 33.74 5.20 17.41 Average: md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: md2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: md3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: md4 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: md5 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: md6 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

I installed the Disable Mitigation Plugin and the Diskspeed docker. I had to reboot for these to take effect, which means parity check cancelled about 70% in, so I guess I have to start over. Attached here is the results of diskspeed. They are all over 100 MB/s. How do I interpret these results against the parity check throughput? I will have to wait until tonight to restart parity check to see if the cpu disable mitigations has any effect. (Too hot during day.)

Thanks both. I will check into those two things and report back.

btw thanks for your troubleshooting support! The Uassigned Device is a USB hard drive dock so nothing to worry about there. I don't think anything should be interfering when it's checking? I really only have a media server docker (jellyfin) and I turn it off before doing the check. I was wondering (maybe) if the unraid update to new linux kernels invoke some harsh mitigation penalty for the crappy intel cpu and so it is slower? Then again I don't know if any of those operations are even required in parity check. Maybe not?

OK attached! Thanks amphora-diagnostics-20201026-1313.zip