DanielCoffey

Members
  • Posts

    268
  • Joined

  • Last visited

Posts posted by DanielCoffey

  1. 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.

  2. 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.

    • Like 1
  3. 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

  4. 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

     

  5. 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?

  6. 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.

  7. 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.

  8. 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.

  9. 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?

  10. 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.

    • Upvote 1