DanielCoffey

The logs will either be in /boot on the flash or in the folder you placed the .sh script? That is where mine were anyway - a pair of files, one with .txt and one with .csv

By default it is on Auto

Looks like the logs are long gone from the flash - we have had so many updates in all that time. Sorry.

I am sorry but I must have cleared those logs a long time ago. I would have cleared them back in 2017 and don't have a local copy of the logs any more. Unless they are buried on the flash I don't know where they are. I can certainly do an extra-long test on the 4.1 script when you have it.

Parity Check complete on the 8Tb WD Reds using the 99% setting... a nice improvement that shaved 90 minutes off the vanilla settings. On Vanilla settings I had checks that were usually around 18h05 and up to 20h25 if there had been an unclean shutdown that had dropped a disk. The old v2 script 99% setting got me a check that came in at 17h25. The new v4 script on the 99% setting brought the check down to 16h29. While it is still a shame that 8Tb checks come on at that long for physical reasons, it is nice to have a tuned array. This is a hobby server rather than a business one so if you make a V4.1 script available I am happy to rerun it to check the layout of HDD reporting and also to see how it homes in on most suitable results with the new margins you have included.

Well the test completed successfully, thank you. My system has eight WD 8TB Red 5400rpm drives in dual parity, five data and one unallocated. The default unraid speed reported was 142.1, the peak test reported by the script was 162.5 and the 99% result was 161.6. The best result the v5.x script could come up with was around 156.0 so the new script definitely explores new areas. LongSyncTestReport_2019_08_05_1907.txt

Just spotted a possible improvement for the script... Prior to running the new script, I reset my Disk Settings to the default values. When I started the script it first ran an initial baseline of current values and then it did a baseline test of unraid default values. After that it went into Test Pass 1. Given that the current values were actually set to unraid default, might it be useful for the script to notice this and skip one of those two tests? Unraid 6.x Tunables Tester v4.0 by Pauven --- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 10min Duration)--- Test 1 - window= 384, thresh= 192: 83.778 GB in 600.150 sec = 142.9 MB/s --- BASELINE TEST OF UNRAID DEFAULT VALUES (1 Sample Point @ 10min Duration)--- Setting all drives to nr_requests=128 for the following tests Test 1 - window= 384, thresh= 192: 83.838 GB in 600.093 sec = 143.1 MB/s

Right, I have installed Screen through the NerdPack and launched it. I assume that once I have started the tuneable script I am free to close the PuTTY window because Screen is keeping a session open on the server, yes? Then I would re-open the PuTTY session at a later time and be able to list (screen -ls) and attach to the Screen session? I am not familiar with Screen but does that sound correct?

Ah, I understand. I wasn't familiar with Screen but now I remember using it once before when preparing the new drives for the array.

OK, silly question but where can I read about Screen for Win10? Trying to google it doesn't work well as the word "screen" is too common when used with Win10. I have PuTTY already of course.

A quick usage question for you , Paul... when running the script through Putty, I assume the PC needs to be awake all the time the script runs as well as the server, yes?

If you clear the tunables fields and then Apply, it resets them to default and changes the little label to the side back to "default" too.

I believe it is as follows... nr_requests is 128 md_num_stripes is 1280 md_sync_window is 384 md_sync_thresh is 192 ( md_sync_window / 2 )

It came in at 17h15 again so it shows that the default settings are at least in the right ballpark. The longer parity checks I had in the past tended to be ones where I had suffered an unclean shutdown or dropped a drive due to cable wiggle and it needed a good look at everything.

I got the script working without issue on my server and got the following results... Best Bang for the Buck: Test 3 with a speed of 151.1 MB/s Tunable (md_num_stripes): 1664 Tunable (md_sync_window): 768 These settings will consume 32MB of RAM on your hardware. Unthrottled values for your server came from Test 35 with a speed of 159.4 MB/s Tunable (md_num_stripes): 5952 Tunable (md_sync_window): 2680 These settings will consume 116MB of RAM on your hardware. This is 91MB more than your current utilization of 25MB. Now to see what a difference it makes to the full Parity check. Times under vanilla settings range from 17h15 to 19h00.

Can I use CA User Scripts to run this without editing it? It does not put scripts in /boot of course.

Excuse me for asking if it has been answered but is there a post in this long thread that explains the setting up and how to use this script?

It supports one fan channel, yes. Splitters are fine as long as they only return one PWM signal back to the motherboard. Some of the cheap ones are simply 4-pin connectors chained one after another and they all share the same PWM signal line. It is usually advised that you find the PWM line and break it on the splitter upstream from the first fan so that only the first fan returns the PWM signal to the board. If yo udon't, the board can get confused as the tach signal looks noisy and it cannot read the correct speed.

sjoerd - you may find that the odd temperature is actually measuring Temperature TO a Threshold rather than actual temperature. If you stress the server you may observe the CPU temps go up and the oddly high temperature go down as it is measuring the inverse.

It sounds like you may have a use case for putting an Aquaero fan controller in your server. When I watercooled I had a temperature sensor on the intake air, another on the water and used the difference to dictate the speed of the fan groups. If the difference was under a certain amount, the radiator fans were shut down.

I have no idea why there is activity on the parity drive though. The array is idle, mover has completed and it is not doing any rebuilds. S3 Sleep does have "Wait for Array Inactivity (exclude Cache)" set as default. If the Spin Down state is unimportant, I suspect my question is why is Parity 1 holding the array active. Would it be better if I started a separate thread? EDIT : Forcing the drives to spin down causes the S3 Sleep plugin to correctly start counting down towards Sleep.

Does the S3 Sleep plugin require disks to be spun down in order to permit sleep? My array has Default Spin Down Delay - Never. Not sure when or why it was set to that but that is the current status. I have checked logging for the plugin and it certainly seems to be checking but keeps reporting disk activity on sdb (my Parity 1 drive). Oct 28 07:06:42 NAS-PLEX s3_sleep: Disk activity on going: sdb Oct 28 07:06:42 NAS-PLEX s3_sleep: Disk activity detected. Reset timers. Oct 28 07:07:42 NAS-PLEX s3_sleep: Disk activity on going: sdb Oct 28 07:07:42 NAS-PLEX s3_sleep: Disk activity detected. Reset timers. Oct 28 07:08:43 NAS-PLEX s3_sleep: Disk activity on going: sdb Oct 28 07:08:43 NAS-PLEX s3_sleep: Disk activity detected. Reset timers.

Thanks - checking it overnight.

Plugin : Dynamix S3 Sleep Version : 2018.02.04 My server (in signature) will not go to sleep with the S3 Sleep plugin installed so I would like to find if there are any logs giving clues to issues. Which folder and log file should I look in for sleep-related messages?

I have a 9201-8i but my SSD drives are both on the motherboard SATA I am afraid (because I have 8 HDDs on the card). There does seem to be a lot of conflicting advice on whether it works or not.