-
Posts
268 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by DanielCoffey
-
-
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.
-
19 minutes ago, Pauven said:
Just wondering, how long does it take to do one pass of a pre-clear (i.e. the final read) for one of your disks?
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.
- 1
-
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.
-
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 )
-
Would that be ECC memory?
-
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.
-
The Read-Check completed without errors so I have unassign/reassigned the problem drives and am now performing the Parity check and Rebuild.
-
Thanks for looking at this. Here is the Diagnostics. The two drives with issues end in ...E049Y and ...DZHAY. They are all WD Red 8Tbs and are under warranty.
Assuming they don't look terrible I will try to just rebuild which will take another day of course. Then I can run Mover since there does appear to be one file in the cache.
-
unRAID ; 6.6.6
Server : As signature
Setup : Dual parity, 5 data, dual ssd cache
Issue : Parity 1 - Disabled, Data 1 - Emulated
Playback from Plex Media Server stopped unexpectedly today and I rebooted both the server and the AppleTV. When the server came back up I started it and both Parity 1 and Data 1 were showing red "X" marks in the Array Devices list.
The server is showing a Read-Check is in progress on the 8Tb drives. I am not sure how this differs from the regular Parity Check and also if a Parity Check is still going to be performed after the Read-Check. It tends to take about 18h40m for a regular Parity Check on these drives.
Apart from waiting, are there any other actions I need to take?
-
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.
- 1
-
If you want to know more about the flash drive and backing it up, SpaceInvaderOne has a youtube channel and has covered that topic.
unraid-tunables-tester.sh - A New Utility to Optimize unRAID md_* Tunables
in User Customizations
Posted
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