Pauven

Short test isn't accurate enough to worry about the numbers. All you should do is look for the behavior that the numbers appear to change in response to different Tunables values. Additionally, there is a possiblity that bare metal behaves differently than virtualized. I'm curious to see the Normal results. Paul

Thank you thank you thank you. I tried to use unix2dos, but found it wasn't installed and gave up. I was frustrated with the idea of having to modify all the echo statements to get the new lines. I tried to use todos, and it never did anything. It always acted like it wanted more parameters. I gave up on todos, but found another solution, a simple sed command to do the conversion. Works a treat: sed -i -e 's/\r*$/\r/' $ReportFile

That's awesome! Hey jumperalex, not to call you out, but wanted to make sure you saw this. The tool isn't just about throwing big numbers and using more RAM. Some servers need more, but some need less. This tool simply discovers what works. While that doesn't negate your question, which is very valid when the values that work consume tons of RAM, it's certainly nice to see results that are so good we don't even have to question them. I get similar results. My tests never report higher than 132 MB/s, yet unRAID is reporting 147 MB/s. That's an 11% variance, much bigger than simply a MiB vs MB conversion factor. I'm really not sure where it is coming from. Interestingly, the variance you have is close to 11% too. Here's mine: Elapsed time: 1 minute Current position: 10.1 GB (0.3 %) Estimated speed: 145.0 MB/sec Estimated finish: 5 hours, 44 minutes Elapsed time: 5 minutes Current position: 43.9 GB (1.5 %) Estimated speed: 147.1 MB/sec Estimated finish: 5 hours, 35 minutes Elapsed time: 10 minutes Current position: 92.2 GB (3.1 %) Estimated speed: 144.4 MB/sec Estimated finish: 5 hours, 36 minutes Here's an overview of the math & logic in the script: First I determine at what point I will begin the stopwatch: TestStartPos=$(( ArraySize / (500000 / TestLen) )) On my server, ArraySize=2,930,266,532 (3TB). For a 5 minute test (TestLen=300) then I don't start measuring until the Parity Check hits 1,758,160 (that's about 1.75 GB). On my server, it takes about 14 seconds to get to that point. Next I start and monitor the parity check, waiting for it to reach the TestStartPos: ### Start a Non-Correcting Parity Check ### mdcmd check NOCORRECT ### Get the Current Position of the Parity Check ### Position=`mdcmd status | egrep mdResyncPos | sed 's/.*=\(.*\)/\1/'` ### Wait until the Current Position reaches the Test Starting Position ### while [ "$Position" -lt "$TestStartPos" ] do Position=`mdcmd status | egrep mdResyncPos | sed 's/.*=\(.*\)/\1/'` echo -ne "\rTest $XSpacer$X$T - md_sync_window=$SyncSpacer$TestSyncWindow - Finding Test Range..." # - Stopwatch: 0.00s - Current Position: "$Position done Notice that there is no "sleep" statement in there, so there is a possibility that frequent mdcmd status checks are slowing down the speed. I'm pretty sure this is spiking CPU usage, as this is how the original version of this script worked, before I changed over to the stopwatch method. That said, technically, I'm not measuring anything yet, so even if this is spiking CPU and slowing speeds, is it having any actual impact? Once the parity check reaches the TestStartPos, I take measurements and start the countdown: StopWatch=$TestLen ### Test Range Entered - Log the Start Time ### StartTime=$(date +%s.%N) #$SECONDS ### Display the countdown timer while the Parity Sync runs ### while [ $StopWatch -gt 0 ] do echo -ne "\rTest $XSpacer$X$T - md_sync_window=$SyncSpacer$TestSyncWindow - Test Range Entered - Time Remaining: "$StopWatch"s " # - Current Position: "$Position sleep 1s let "StopWatch-=1" done I grab the StartTime so I get the exact moment I started the actual measurement portion of the test. I then begin the countdown, which is easy on the CPU because the script is primarily sleeping during this portion, allowing the parity check to run unhindered. When the countdown completes, I take the final measurements: ### Test Range Exited - Log the End Time ### Position=`mdcmd status | egrep mdResyncPos | sed 's/.*=\(.*\)/\1/'` EndTime=$(date +%s.%N) #$SECONDS ### Cancel the Parity Check ### mdcmd nocheck Notice that I grab the Position first, then grab the End Time, then end the parity check. Perhaps I could grab the End Time before grabbing the Position, but I doubt the lag time in grabbing the Postion is enough to cause a huge swing in MB/s calculations. Finally, I do the math: ### Calculate the test duration and resulting speed ### RealDuration=`echo "$EndTime $StartTime" | awk '{ printf( "%0.3f\n", ($1 - $2) )}'` BytesProcessed=$(( Position - TestStartPos )) RealSyncSpeed=`echo "$BytesProcessed $RealDuration" | awk '{ printf( "%0.1f\n", (($1 / $2) / 1024) )}'` The duration is the actual start time minus the actual end time, to 3 decimal places. Should be pretty accurate. Bytes Processed is the Position the parity check got to when the test ended, minus the TestStartPos since I don't measure from 0. These are unconverted unRAID #'s, so should be pretty accurate. Finally I get the MB/s by dividing the actual Bytes Processed (again these seem to be KB and not Bytes) by the actual elapsed test time, and then divide that result by 1024 to convert from KB/s to MB/s. I don't know what Lime-Tech is doing, but best I can tell, my logic is pretty sound. If there's a problem, I'm just not seeing it. If I divide by 1000 instead of 1024, that only gives me an increase of 2.4%, far too low to fix the 11% variance. Perhaps the BytesProcessed, being in KB, has already been divided by 1024 from the true Bytes, in which case I could do ByteProcess*(1024/1000) to modify that conversion, and also use 1000 when I convert to MB/s. But that would only raise the MB/s by about 4.9%, still far less than the 11% variance. If someone sees something I'm missing, please help me out. Perhaps Lime-Tech can give us some insight. -Paul

Not a silly question at all. Yes, new in v4, I spin up each idle drive, one-by-one with a 2 second delay inbetween, so it is a staggered spin-up. That said, this was just a cosmetic feature. Because I don't start measuring from the beginning of a parity check, but rather 15+ seconds into it, the impact of the automatic spin-up was already negated in the results. I didn't like how the script appeared to hang during an automatic spin-up, every time it made me think something was wrong. With my new spin-up code, it never hangs and you can always tell what the script is doing. -Paul

Okay, wow. I appreciate the info. What's the general consensus, do I need to target 6.1.9 too? I understand the reservations to upgraded to a remotely authorized version, but I'm hopeful 6.2 final is close at hand. Paul

I'm not liking these results. There's not much consistency, even at 5 minutes. Test | num_stripes | sync_window | nr_requests | sync_thresh | Speed --------------------------------------------------------------------------- 1 | 1536 | 768 | 128 | 767 | 138.6 MB/s 2 | 1536 | 768 | 128 | 384 | 130.5 MB/s Test | RAM | stripes | window | reqs | thresh | MB/s | thresh | MB/s ------------------------------------------------------------------------ 7 | 87 | 1536 | 768 | 128 | 767 | 101.1 | 384 | 88.0 Tests 1 & 2 were from the nr_requests test, and ran for 10 minutes each (so more accurate): Test 7 tested the exact same values from tests 1 and 2, just at 5 minutes instead of 10, with downward swings of 37.5 MB/s and 42.5 MB/s. That's not accurate at all. scottc had similar results, I recommend you read my post to him: https://lime-technology.com/forum/index.php?topic=29009.msg493338#msg493338 Thanks, Paul

I wouldn't be opposed to you running this on 6.1.9. I'm curious how it would behave. No idea if it is compatible, though, so no pressure. I appreciate the extra effort!!! Your Short Auto results look very promising. Can't wait to the the result of the Normal Auto. Thank you thank you thank you. I tried to use unix2dos, but found it wasn't installed and gave up. I was frustrated with the idea of having to modify all the echo statements to get the new lines. Good catch, that's my mistake. I pulled the Fastest/Thriftiest/Recommended calculations out of the Short Auto test, but failed to pull the ability to Apply or SAVE the values from the Short Auto run. You definitely should NOT be saving or using values from the Short test, it's just not accurate enough. I'll fix for the next beta. Thanks, Paul

Correct, the values are not accurate, but they do show a nice linear progression of speeds from 44 MB/s at low values to 115 MB/s at high values. That alone is all the confirmation you need that you should run a Normal length test. Your server responds well to changing the tunables values. --- FULLY AUTOMATIC TEST PASS 1a (Rough - 4 Sample Points @ 30sec Duration)--- Test | RAM | stripes | window | reqs | thresh | MB/s | thresh | MB/s ------------------------------------------------------------------------ 1 | 37 | 768 | 384 | 8 | 383 | 54.3 | 192 | 43.8 2 | 63 | 1280 | 640 | 8 | 639 | 74.3 | 320 | 64.5 3 | 88 | 1792 | 896 | 8 | 895 | 102.3 | 448 | 90.0 4 | 113 | 2304 | 1152 | 8 | 1151 | 115.2 | 576 | 115.1 Thanks for sharing! Paul

Awesome, you've got a semi-bizarro server! The script triggered test 1b, to test values lower than stock unRAID values. Awesome. When focusing on the md_sync_thresh=50%Max (rightmost column), and if you put the 1b results before the 1a results, you can see a gradual climb from 160 MB/s at 64 to a peak around 188 MB/s in the 320-384 range, and from there it tapers off to about 182 MB/s. When looking at the md_sync_thresh=Max-1 column (3rd column from right), it seems nearly maxed out regardless of the other values set. Can't wait to hear the parity check results. Sure hope we saved you some memory with no sacrifice in speed. Fingers crossed, it might even be faster... I see what you're saying. I'm trying to depreciate the Short test, make it quick and easy to get out of the way, but you make a good point. I'm not sure there is a right answer here, at least not on the current path. I'm beginning to think that the Short Auto test needs to be replaced by a different test altogether. Perhaps just the nr_requests test, which for me is illustrating better than anything else if the server responds to changing the Tunables. In my head, I'm thinking of running the nr_requests test 3 times, once at stock unRAID md_sync_window, again at 768, and again at 1536. With 5 minute length tests, the above would complete in 1 hour. With 2.5 minute tests, just 30 minutes. I'm also thinking of adding in a calculation that compares the fastest to the slowest, and if it is beyond a certain threshold, recommend running the Normal Auto. But as of right now, these are just ideas. I'm certainly open to suggestions. That is a very interesting idea!!! To calculate the speeds, I using 1024 based notation, not 1000. I just mocked up the impact in Excel, and a 100 MB/s speed with the current 1024 notation becomes 102.4 MB/s. Slightly higher, but not the 8% you're looking for, just 2.4%. There's always the possibility that Lime-Tech doesn't have the math exactly right, though I'd be surprised if that was the case. Perhaps my math is bad too... There's another variable to keep in mind too: the unRAID value is the average from the beginning of the parity check. My scripts value doesn't start at the beginning, but rather waits a few seconds for things to settle down, before it begins measuring. Any early spikes or slowdowns in performance that occur in the first 15 seconds are being filtered out by my script, but not by unRAID. -Paul

Yes, for two reasons. Short test is too short to be accurate. You could run it a dozen times and get differing results each time. Also, I made big changes to the Short test in this beta version. The goal of the Short test is to give you a preview of your server's behavior to changing the Tunables before committing 10+ hours to actual testing. The Normal test should be mostly accurate. -Paul

unRAID 6 NerdPack But please suggest screen, don't force. Cool, thanks! Quick question, does the NerdPack install all of the utilities, or can you pick and choose? I've already got burned by a plugin adding a symlink, I don't think I'd want the beta version of lshw installed since I'm using it in my script. Totally agree on suggest vs force. -Paul

30 second tests are very inaccurate. During development, I don't have time to wait around for 30 second tests (especially when running 80+ of them for a test, adds up), so I cheat and run 3 second tests. The results are hilarious. In the old 2.2 version of the script, going from memory so I may be wrong, I think the normal test length was 3 minutes. I had tried to set it to the shortest amount of time that produced an accurate answer. With unRAID v6.2, I found that 3 minutes wasn't long enough anymore, so I tested 4 minutes and finally settled on 5 minutes. Of course, this was all developed on my server, and every server is unique. I've seen some server results posted here that, surprisingly, had semi-accurate results for 30 seconds. I imagine the opposite is true, and that for some servers (scottc's, for example), 5 minutes isn't long enough. Anyway, long story longer, the goal of the 30 second test isn't to give accurate results, but rather to determine if changing the values does anything at all to the server. From what I'm seeing, it does seem to provide that answer. Me too! Hopefully you used the numbers from the Normal length test, and not the Short. -Paul

Awesome ideas, thanks ljm42! Quick question: On unRAID v5, I used unMenu to handle installing my extras like Screen. Now on 6.x, I don't use unMenu anymore. I looked for a plugin to install screen for me, but didn't see one. Did I just miss it? Any guidance? Thanks, Paul

UTT v4 Beta Testers, v4b3 is now available for download. Changes: Removed obsolete path from mdcmd Fixed drive specific nr_request values querying bug Changed lshw flag from -businfo to -short Drastically reduced the # of test points in a Short Auto, now completes in <21 min Removed Fastest/Thriftiest/Recommend subreport from Short Auto Combined a/b Test rows in the report into a single line, easier to read and shorter! Enjoy, Paul

Excellent! Thanks!

I guess your server isn't so boring after all, eh? Yes, that is confusing. It helps to keep in mind that, technically, we are measuring two different things. The parity check results on your server are measuring how long it took to read the full 4TB from your drives, and calculating the average speed from a single 8-9 hour test. Nice speeds by the way. When running the Normal Auto, the script is measuring how much data was processed in 5 minutes, from almost the beginning of your drives, not the entire thing. We measure from the beginning of the drive for two reasons: 1) it's a lot easier, and 2) typically your fastest speeds occur here, so optimizing here hopefully optimizes for the entire run. There are exception cases (having an old and slow 500 GB drive in the mix with fast 8TB drives) that would prevent the beginning from being the fastest, but those scenarios don't apply to your server. The goal isn't to make the actual average parity check speed match these tests, but rather to find what parameters produce higher speeds in the test, which hopefully will produce faster real-world parity check speeds. That said, I would typically expect these tests to report higher speeds, not lower, and certainly not by half. It's certainly possible that "something" is slowing down the very beginning of your parity checks. If this is true, I would imagine you would see this in the GUI as well. Start up a parity check, and refresh the GUI about every 30 seconds. See how long it takes before the GUI reports high speeds. It might crawl along for a minute or two, then jump up to 150MB/s, but in a 5 minute test, a couple minutes of crawling can really drop the tested speeds. If it turns out that the beginning of your parity checks really are slow (and if the script doesn't give you values to fix it), it's probably smart to run a SMART report, to see if one of your drives is smartin'. Could be some bad sectors at the beginning of a drive slowing things down. This is unlikely, and I'm not trying to scare you, but it may be worth double-checking. I agree. Out of my hands, sorry. I have noticed that, regardless of how many parity checks get started and canceled, I never see more than one History row per day Just noticed I have more than one per day now. Not sure if it takes the first or last daily result, but I'm guessing it is one of the two. I see a some inconsistency from the first pass to the second pass, mostly in the lower ranges. It does appear to me that your server likes higher md_sync_window values (1536 looks good), nr_requests=8, and higher md_sync_thresh values (1535). Use 3072 for md_num_stripes, and run a parity check. Perhaps we can drop that already excellent parity check time. But you may want to run that other test first, starting a parity check in the GUI and watching the first few minutes to see how it behaves. Thanks, Paul

Nice numbers. Very comparable.

Thanks RobJ. I was just looking at lsscsi myself. I like this, which is giving me the driver (I think), a nice touch: "lsscsi -H" [0] usb-storage [1] mvsas [2] mvsas [3] mvsas combined with this: "lsscsi -s" [0:0:0:0] disk Patriot Memory PMAP /dev/sda 4.00GB [1:0:0:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdb 3.00TB [1:0:1:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdc 3.00TB [1:0:2:0] disk ATA Samsung SSD 840 BB6Q /dev/sdd 1.00TB [1:0:3:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sde 3.00TB [1:0:4:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdf 3.00TB [1:0:5:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdg 3.00TB [1:0:6:0] disk ATA WDC WD30EFRX-68E 0A82 /dev/sdh 3.00TB [2:0:0:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdi 3.00TB [2:0:1:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdj 3.00TB [2:0:2:0] disk ATA WDC WD30EFRX-68E 0A82 /dev/sdk 3.00TB [2:0:3:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdl 3.00TB [2:0:4:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdm 3.00TB [2:0:5:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdn 3.00TB [2:0:6:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdo 3.00TB [2:0:7:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdp 3.00TB [3:0:0:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdq 3.00TB [3:0:1:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdr 3.00TB [3:0:2:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sds 3.00TB [3:0:3:0] disk ATA WDC WD30EFRX-68A 0A80 /dev/sdt 3.00TB But none of it is exactly what I want. I think the only way to get the output I want is to grab all the values, put them in an array, and generate the output myself. Another PITA. Here's my goal - all the data is available, just not in one spot: [0] scsi0 usb-storage [0:0:0:0] Flash Patriot Memory PMAP /dev/sda 4.00GB [1] scsi1 mvsas HighPoint Technologies, Inc. [1:0:0:0] Disk17 WDC WD30EFRX-68A 0A80 /dev/sdb 3.00TB [1:0:1:0] Disk18 WDC WD30EFRX-68A 0A80 /dev/sdc 3.00TB [1:0:2:0] Cache Samsung SSD 840 BB6Q /dev/sdd 1.00TB [1:0:3:0] Parity2 WDC WD30EFRX-68A 0A80 /dev/sde 3.00TB [1:0:4:0] Unassigned WDC WD30EFRX-68A 0A80 /dev/sdf 3.00TB [1:0:5:0] Unassigned WDC WD30EFRX-68A 0A80 /dev/sdg 3.00TB [1:0:6:0] Parity WDC WD30EFRX-68E 0A82 /dev/sdh 3.00TB [2] scsi2 mvsas HighPoint Technologies, Inc. [2:0:0:0] Disk1 WDC WD30EFRX-68A 0A80 /dev/sdi 3.00TB [2:0:1:0] Disk2 WDC WD30EFRX-68A 0A80 /dev/sdj 3.00TB [2:0:2:0] Disk3 WDC WD30EFRX-68E 0A82 /dev/sdk 3.00TB [2:0:3:0] Disk4 WDC WD30EFRX-68A 0A80 /dev/sdl 3.00TB [2:0:4:0] Disk5 WDC WD30EFRX-68A 0A80 /dev/sdm 3.00TB [2:0:5:0] Disk6 WDC WD30EFRX-68A 0A80 /dev/sdn 3.00TB [2:0:6:0] Disk7 WDC WD30EFRX-68A 0A80 /dev/sdo 3.00TB [2:0:7:0] Disk8 WDC WD30EFRX-68A 0A80 /dev/sdp 3.00TB [3] scsi3 mvsas HighPoint Technologies, Inc. [3:0:0:0] Disk9 WDC WD30EFRX-68A 0A80 /dev/sdq 3.00TB [3:0:1:0] Disk10 WDC WD30EFRX-68A 0A80 /dev/sdr 3.00TB [3:0:2:0] Disk11 WDC WD30EFRX-68A 0A80 /dev/sds 3.00TB [3:0:3:0] Disk12 WDC WD30EFRX-68A 0A80 /dev/sdt 3.00TB That's just a starting point too. It would be even better if the controllers showed the model or chipset, instead of just a generic identifier. I'm running a 2620A, a detail I've never seen anywhere in the system. Looking at the above, my first thought is: would I get better performance if I moved Parity2 to a different controller? I think this is 3 or 4 different sources of data, some of which I'm already grabbing and putting into arrays, but if someone wants to help me with the logic, I'd be much obliged. -Paul

I'm not home now and server is off, but I'll check when I get home, though I'm not sure what to check... Nevermind, I found the bug. When I was grabbing the values, I accidentally hard coded to only pull the value from disk "sdj", and used that value for all disks. This means two things: 1) The values reported per disk were wrong at the top of the report, and 2) The routine that restores all the values to their original state at the end of the script did so incorrectly. The good news is that, even if you SAVED the values, writing nr_requests to disks.ini, if you had individual per-disk values (perhaps in the extra or go file, not sure where they would go), then that data was untouched, and a server reboot will restore those values. Apologies if this affected anyone. -Paul

Your help is definitely appreciated. It seems that in the 3 years since I first wrote this script, we've yet to unravel exactly what these values are doing. If anyone knows, it's probably Tom, but perhaps not even him. What we're doing is more akin to alchemy than science.

Beta Testers, v4b3 will definitely be dropping today. I'm going to start coding the changes now. Planned changes: remove mdcmd path reduce the number of test points in a Short Auto change the lshw output to try it without the -businfo flag tweak the report layout to reduce the total # of lines/chars, since the report has gotten just way too big. If there are any other bugs/changes/requests, please let me know. johnnie.black, if you have any idea on why those drive specific nr_requests values were null on Tower4, please let me know. And if anyone has suggestions on how I can better list the controllers and their attached drives, I would be most appreciative. Thanks, Paul

Basically I found those setting worked great on all my servers, independent of the controllers used. At the time I used your old script, and because it didn't test for md_sync_thresh I manually entered round values, e.g., I would do 4 runs with sync_thresh manually set at 500, 1000, 1500 and 2000 and picked the value with the best result. I also found that in most cases there was only a noticeable difference when the value approached half sync_window, e.g, with a sync_window set at 2048, performance was very similar with sync_thresh set at 1500, 2000 or 2047. Very interesting, thank you for sharing. Do you recall what happened with the 25% value, 500? I'm guessing that because you've gone with high values on most (all?) your servers that 500 was just pants. But it makes me wonder, if a server works better at 50% than 99%, would it work even better at 25%, or 10%.

This makes me feel similar to how I feel after visiting the Georgia Aquarium, then returning home to see my rinky-dink aquarium. You have challenges that are completely different to us amateurs... I'd be curious what kind of power numbers you get on your collection of servers. My 42TB array, with a couple parity and an ssd cache (17 total drives) consumes about 140W all spun up. I worked really hard to make it very energy efficient (for a server of this size). I see it didn't pick up any nr_requests being set at the drive level. That's unexpected. Or I have a bug in the script. Can you help troubleshoot? --- INITIAL BASELINE TEST OF CURRENT VALUES (1 Sample Point @ 30sec Duration)--- Test | RAM | num_stripes | sync_window | nr_reqs | sync_thresh | Speed ----------------------------------------------------------------------------- 1 | 138 | 4096 | 2048 | 8 | 2000 | 145.5 MB/s So after seeing the results for all the different servers, I'm beginning to recognize that these are your favorite go-to values (well, I guess you set num_stripes a little lower on this one), and with good reason, as they seem to be giving you good results. I'm still hopeful Normal Auto test length will let the script get close to these results, but because your ratios are different than what the test is doing, there's a good possibility it won't be able to match your results. --- FULLY AUTOMATIC nr_requests TEST 1 (4 Sample Points @ 60sec Duration)--- Test | num_stripes | sync_window | nr_requests | sync_thresh | Speed --------------------------------------------------------------------------- 1 | 1536 | 768 | 128 | 767 | 106.0 MB/s 2 | 1536 | 768 | 128 | 384 | 85.1 MB/s 3 | 1536 | 768 | 8 | 767 | 100.3 MB/s 4 | 1536 | 768 | 8 | 384 | 74.9 MB/s Fastest vals were nr_reqs=128 and sync_thresh=99% of sync_window at 106.0 MB/s Once again, since the first nr_requests test came up with the wrong answer (so I assume) the rest of the test goes downhill from here. Hopefully Normal Auto gets this right. The Fastest Sync Speed tested was md_sync_window=1208 at 127.0 MB/s Tunable (md_num_stripes): 2416 Tunable (md_sync_window): 1208 Tunable (md_sync_thresh): 1207 Tunable (nr_requests): 8 This will consume 81 MB with md_num_stripes=2416, 2x md_sync_window. This is 57MB less than your current utilization of 138MB. Yup, never even got close. But that's not the point of the Short Auto. Completed: 1 Hrs 1 Min 20 Sec. 1hr, that's the point of the Short Auto, it's quick so you don't waste a lot of time, and based upon what I see, we can determine that your server responds well to changing the tunables. Since the short auto is turning out such crap results, I'm gonna tweak it to make it faster, by removing a lot of the test points. Even with half the test points, it should still tell us whether it is worth running a Normal Auto 16hr test. Outputting lshw information for Drives and Controllers: Bus info Device Class Description =================================================== pci@0000:01:00.0 storage Serial ATA II RAID 1430SA pci@0000:00:1f.2 storage 6 Series/C200 Series Chipset Family SATA AHCI Controller usb@2:1.1 scsi0 storage scsi@0:0.0.0 /dev/sda disk 7862MB DT Micro /dev/sda disk 7862MB scsi3 storage scsi@3:0.0.0 /dev/sdb disk 4TB WDC WD40EZRX-00S scsi4 storage scsi@4:0.0.0 /dev/sdc disk 4TB WDC WD40EZRX-00S scsi5 storage scsi@5:0.0.0 /dev/sdd disk 8001GB ST8000AS0002-1NA scsi6 storage scsi@6:0.0.0 /dev/sde disk 8001GB ST8000AS0002-1NA scsi7 storage scsi@7:0.0.0 /dev/sdf disk 8001GB ST8000AS0002-1NA scsi8 storage scsi@8:0.0.0 /dev/sdg disk 8001GB ST8000AS0002-1NA scsi9 storage scsi@9:0.0.0 /dev/sdh disk 8001GB ST8000AS0002-1NA scsi10 storage scsi@10:0.0.0 /dev/sdi disk 4TB WDC WD40EZRX-00S Once again, it looks like no drives are connected to the 1430. Can anyone give me advice on how to make it so that the drives connected to the controller are listed below the controller? The results are beautiful on my server, so I didn't know this would be a challenge: Bus info Device Class Description ======================================================== pci@0000:04:00.0 scsi1 Storage HighPoint Technologies, Inc. scsi@1:0.0.0 /dev/sdb Disk 3TB WDC WD30EFRX-68A scsi@1:0.1.0 /dev/sdc Disk 3TB WDC WD30EFRX-68A scsi@1:0.2.0 /dev/sdd Disk 1TB Samsung SSD 840 scsi@1:0.3.0 /dev/sde Disk 3TB WDC WD30EFRX-68A scsi@1:0.4.0 /dev/sdf Disk 3TB WDC WD30EFRX-68A scsi@1:0.5.0 /dev/sdg Disk 3TB WDC WD30EFRX-68A scsi@1:0.6.0 /dev/sdh Disk 3TB WDC WD30EFRX-68E pci@0000:05:00.0 scsi2 Storage HighPoint Technologies, Inc. scsi@2:0.2.0 /dev/sdk Disk 3TB WDC WD30EFRX-68E scsi@2:0.3.0 /dev/sdl Disk 3TB WDC WD30EFRX-68A scsi@2:0.4.0 /dev/sdm Disk 3TB WDC WD30EFRX-68A scsi@2:0.5.0 /dev/sdn Disk 3TB WDC WD30EFRX-68A scsi@2:0.6.0 /dev/sdo Disk 3TB WDC WD30EFRX-68A scsi@2:0.7.0 /dev/sdp Disk 3TB WDC WD30EFRX-68A scsi@2:0.0.0 /dev/sdi Disk 3TB WDC WD30EFRX-68A scsi@2:0.1.0 /dev/sdj Disk 3TB WDC WD30EFRX-68A pci@0000:06:00.0 scsi3 Storage HighPoint Technologies, Inc. scsi@3:0.0.0 /dev/sdq Disk 3TB WDC WD30EFRX-68A scsi@3:0.1.0 /dev/sdr Disk 3TB WDC WD30EFRX-68A scsi@3:0.2.0 /dev/sds Disk 3TB WDC WD30EFRX-68A scsi@3:0.3.0 /dev/sdt Disk 3TB WDC WD30EFRX-68A usb@1:1.4 scsi0 Storage scsi@0:0.0.0 /dev/sda Disk 4005MB Patriot Memory /dev/sda Disk 4005MB Thanks, Paul

Hmmm, that didn't go that well at all. I'm gonna chalk that up to this being a Short test, and there's just not enough accuracy for the logic to work with 30 second tests (or even 60 seconds, in the case of the nr_requests). To minimize the total number of tests that are being run, the first test I run is to try and determine the best nr_requests value, and then use that for the remaining tests. Unfortunately, if this first test doesn't get the right answer, then the first round of sync_window tests are kinda pointless. Which then leads to the second nr_requests test occuring in the wrong range, and the final pass being pretty worthless to. This seems to be what happened here. The longer Normal Auto test should address this. It runs the nr_requests tests for 10 minutes, so basically 10x more accuracy, to set up the rest of the tests for success. Thanks, Paul

I know this was a Short test so the results aren't that accurate, but none of the results came close to your current baseline. I have to ask about the ratios you are using. For the tests, I'm using num_stripes = 2x sync_window, but you've gone 384 higher. Any rationale behind that? Also, while you're using a high value for nr_requests, you're not using sync_window-1, but sync_window-48. How did you get to these values? A Normal length test is required to see if this is just a fluke or if you've truly got better values, but color me interested. Thanks, Paul