moose

Even though there is a BIOS menu title with "PnP" there is no actually PnP (Plug and Play) option in BIOS to change. I also checked the BIOS manual from Super Micro.

I'd like to see if X9SCM-F users can share the combination of BIOS version(s) and unRAID version(s) they have successfully used and are using. If possible, could you review the v2.0b BIOS settings I have here and let me know if you see anything I should change? (If you are super-motivated, you could post similar screenshots of the relevant BIOS pages for your setup). My v2.0b BIOS screenshots: http://imgur.com/a/SQxe9 The problem I and a few others are having is a slow write speed (~ 1 MB/s) with the X9SCM-F and 5.0-rc8a. I'm guessing some X9SCM-F/5.0-rc8a users have tested and do have good write speeds. Anyway I know we're not suppose to cross-post but I just wanted to see what BIOS/unRAID version combinations were successful for other X9SCM-F users. Other thread: http://lime-technology.com/forum/index.php?topic=22675.0 My testing: BIOS 1.1a, 2.0a, 2.0b => slow write speed with 5.0-rc8a, however acceptable write speed with 4.7 through 5.0-rc5. I also sent an email to Tom (and he posted on the other thread) and is looking into it. Thanks for any assistance!

ok, I'll check the BIOS. I just finished uploading screenshots of all default (current) BIOS settings to Imgur. Please see this link for all X9SCM-F (v2.0b) BIOS settings: http://imgur.com/a/SQxe9

The results of the 2TB "data disk rebuild" and 3TB "correcting parity check" are below. The seconds stated were obtained from the system log (attached). My other MB/s speeds earlier stated in this thread were from "observation" of the unRAID Main webpage (and multiple browser window refreshes), so those previously stated MB/s values were incorrect. Going forward I'll use the system log file to measure the MB/s once the processes complete. 2TB data disk rebuild in 67825 seconds, => 29.5 MB/s. 3TB correcting parity check in 41910 seconds, => 71.6 MB/s. syslog-2012-01-02.txt

When I initially had the slow write problem, I downgraded from v2.0a to v1.1a => problem still existed. I then went back to v2.0a and then to v2.0b (current) => problem still exists, so I don't think switching BIOS makes a difference. If you do downgrade BIOS (at least to v1.1a), you need to follow a specific sequence to avoid other issues. Here is where I discuss going from v2.0a to v1.1a BIOS: http://lime-technology.com/forum/index.php?topic=22675.msg202154#msg202154 You can find your BIOS version in unRAID in the "system log", "Utils" -> "System Log", then scroll through the log sequence to locate.

With earlier testing I've had the same slow write results with BIOS v1.1a, v2.0a and v2.0b (current) on the X9SCM-F.

Helmonder, I noticed this when I first loaded 5.0-rc8a and started to run the preclear script on the two drives I have in my test unRAID server. Step #2 (write zeros to the disk) was painfully slow, so I precleared the drives in the 4.7 server. Then once 5.0-rc8a was setup with the two precleared drives, I noticed that I when I would write files to the array it was again very slow but the read speed was good. Through various testing with multiple 5.0 Betas and RCs, it appears that with 5.0-rc6 (and onward) that the slow write speed is present and with 5.0-rc5 and below write speed is good. Looking at the unRAID release log (http://lime-technology.com/wiki/index.php/Release_Notes), one change (as Tom noted above) was a change to kernel 3.4.11, which fixed various other issues. Tom also indicated that he reviewed the kernel configuration and did not see anything obvious. Tom is looking into the problem. I did see you have a similar thread but a slightly higher write speed (5 - 6 MB/s). I'm sure this will get resolved. (Also FWIW - In one of the earlier 5.0-rc8a tests I upgraded Samba from 3.6.7 to 3.6.8 using the process outlined in the main 5.0-rc8a announcement thread - no change in write speed performance.)

The data disk rebuild is rebuilding the data disk at ~ 40 to 50 MB/s. The parity and data disks are both plugged into the 6 Gbps (on-board) SATA ports of the X9SCM-F (Intel Cougar Point 6-port SATA AHCI Controller, (2) 6 Gbps & (4) 3 Gbps SATA ports). The parity drive is rated at 6 Gbps and data drive is rated at 3 Gbps, so it seems logical that the data disk rebuild would have approximately 1/2 the "parity sync" and "parity check" speeds, correct?

The E3-1270 CPU has (4) cores, complete specs here: http://ark.intel.com/products/52276/Intel-Xeon-Processor-E3-1270-8M-Cache-3_40-GHz. I set the BIOS to enable only (1) CPU core and still the ~ 1 MB/s write speed to the cache and data disks. Yes, the parity check speed was ~ 140 MB/s in earlier testing. I'll re-test the parity check speed. Edit: Parity sync (w/ 3TB parity drive and 2TB data drive) is running at ~ 90 MB/s. Parity check (non-correcting) is running at ~ 110 MB/s.

Following steps were completed: [*]Issue the "dd if=/dev/zero bs=1M count=1 of=/dev/sdX" commands from console, power down the unRAID server. [*]Quick format the flash drive and unzip "5.0-rc8a AiO.zip". [*]Copy "pro2.key" file to /config (add cache drive functionality). [*]Run "make_bootable.bat" command on the flash drive. [*]Install flash, boot unRAID server, navigating to the main page. [*]Assign disk1 (2TB) as data and disk2 (3TB) as cache, no parity disk assigned. [*]Format disk2 (cache), was no option to format disk1 (data). [*]Test read/write speeds from a Win7 client directly to disk2 (cache). Same slow write speed result (~ 1 MB/s) and normal (fast) read speed result. I would have thought I would have been able to format disk1 (data); I don't believe this would make any difference with this test, but I'll start over from step #1 and see if the data disk is able to be formatted in step #7 on another full test sequence. Edit: Same result (slow write) on second full test sequence.

I'm not sure if any 5.0-rc8a users have a E3-1270 processor (in a X9SCM-F motherboard), however attached are screenshots of the X9SCM-F bios config options for my processor, E3-1270, is there anything here that might be causing the 5.0-rc8a slow write problem? I changed the "power technology" option from "energy efficient" to "custom" and a few extra menu options were presented (so I took a screenshot with "custom"). The second screenshot is the processor "turbo boost technology" options. If anyone sees a parameter that might be set incorrectly which might explain the slow write speed with 5.0-rc8a , please let me know so I can modify and retest to see if it resolves the problem. syslog is also attached. Just to reiterate, with 5.0-rc5 and earlier releases, write speed is acceptable/normal. syslog.txt

Suggestions to troubleshoot would include: 1. Test/replace Ethernet cables. Do you have a loose/damaged RJ45 connector? Are you using a damaged Ethernet RJ45 coupler? 2. Do you own (or can you borrow) a LAN connectivity tester? This can verify your CAT5/CAT6 cables are good or bad. 3. Is your router/switch going up and down? 4. Try connecting you unRAID server directly to your router/switch with a good Ethernet cable and likewise (directly to your router/switch) for your client computer and retest the read/write sequence. 5. Try a different Ethernet adapter if you have one available.

a) 3TB drive to 6 Gb motherboard SATA port b) 3TB drive to SAS2LP SATA port c) 3TB drive to SASLP SATA port d) 3TB drive to 3 Gb motherboard SATA port I followed the suggested test sequence...only the 3TB drive installed, one cable connected to the 3 TB drive. Cases (a), (b), © and (d) produced the same slow write speed. The motherboard has 6 Gb and 3 Gb SATA ports so I tested each of these ports independently, added a 4th test sequence (d). It did appear that with some of the test cases that the write speed started at ~ 10 MB/s for a split second (initial burst) and quickly dropped/settled to the ~ 1 MB/s write speed within 5 seconds or so and remained at ~ 1MB/s until the 1 GB test file completed writing to the unRAID server. Edit: FYI - reverting 5.0-rc8a back to 5.0-rc5 (by replacing the bzimage and bzroot files) solves the slow write problem with all 4 SATA port scenarios.

I followed the steps (verbatim) outlined by limetech...no difference in results. I still get the ~ 1MB/s write speed when writing directly to either disk1 or disk2. 1. Issue the "dd if=/dev/zero bs=1M count=1 of=/dev/sdX" commands from console, power down the unRAID server. 2. Quick formatting the flash drive. 3. Unzipping 5.0-rc8a AiO to the flash. 4. Running the "make_bootable.bat" command on the flash. 5. Installing the flash, booting the unRAID server, navigating to the main page. 6. Assigning disk1 and disk2, no parity disk is assigned. 7. Formatting disk1 and disk2. 8. Testing read/write speeds from a Win7 client directly to disk1 and disk2. Same slow write speed results for both disks. When writing to each disk (one at a time), I got the 1 MB/s write speed, however when writing to one disk and then attempting to write to the second disk (both disks at the same time), the second disk write was initially unresponsive, then started writing at ~ 20 KB/s until I cancelled the operation to write to the first disk, then the write to the second disk started to speed up to the ~ 1 MB/s threshold. It seems like something is saturated at the 1 MB/s write threshold.

Thank you limetech for the detail to troubleshoot/resolve. I'm currently out of town until Friday, however before I left town, I started 4k boundary preclearing the 3TB and 2TB drives in the "test server" with 5.0-rc5 since 5.0-rc5 had no write speed issues based on my earlier testing. So when I get back on Friday, I will continue with the steps you've outlined above to see if this resolves the write speed problem.

Further testing has produced the following results: Typical preclear write speeds (~70 MB/s to 90MB/s) in step #2 (zeroing the disk), with 5.0-rc5 or earlier RCs or Betas Upgrading to 5.0-rc6 or 5.0-rc8a produces a preclear write speed (~1MB/s) in step#2 (zeroing the disk). With each beta or RC change, all I am doing is replacing the bzimage and bzroot files on the flash drive (nothing else) and the only add-on is unmenu. I'm going to take a wild guess and question whether there is some incompatibility with my processor (E3-1270). Is anyone running a X9SCM-F motherboard and E3-1270 processor and successfully able to achieve normal disk write speeds?

I have performed the following test scenarios: 1. Formatted a Lexar 8Gb flash drive, then installed 5.0-rc8a AIO (no add-ons, except un-menu). Preclearing a 2TB drive yields a ~ 1MB/s write in step #2 (zeroing the disk) 2. Stopped the preclearing process (CTRL-C) and downgraded 5.0-rc8a to 4.7 by overwriting only the "bzimage" and "bzroot" files on the flash drive. 3. Preclearing the same 2TB drive yields a ~ 90MB/s write in step #2 (zeroing the disk). The 2TB drive is connected directly to one of the X9SCM-F on-board SATA ports. Could there be a kernel incompatibility with the X9SCM-F motherboard and E3-1270 processor? Why would there be such a disparity between the preclear write speeds?

I downgraded to see if going from v2.0a to v1.1a would correct the slow write speed I am having with the X9SCM-F and v5.0-rc8a. With testing I suspected the X9SCM-F bios was corrupt. I reinstalled v2.0a but no change, so I wanted to see if downgrading to v1.1a would make any difference...it didn't. I eventually plan to use EXSi on this server, but wanted to verify that I had v5.0-rc8a correctly running on this motherboard outside of EXSi first. FYI - This thread summaries the slow read speed I'm having with the X9SCM-F and v5.0-rc8a: http://lime-technology.com/forum/index.php?topic=22675.0

Tower login: root Linux 3.4.11-unRAID. root@Tower:~# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 25090 MB in 1.99 seconds = 12582.67 MB/sec Timing buffered disk reads: 434 MB in 3.01 seconds = 144.35 MB/sec root@Tower:~# exit

Parity is already unassigned. Please see attached screenshot. I haven't reassigned the 3TB parity disk since your post on 9/22/12 asking me to try without parity because reassigning parity would require a parity rebuild (multiple hour delay).

Unfortunately I only have 1 data disk on this server. I've tried multiple Intel network cards (on-board and add-on) and SATA controllers (on-board and add-on). Based on chronological testing in this thread, I've ruled out the network, adapters, controllers and WIN7 client. The problem is with v5.0-rc8a and the X9SCM-F, however numerous others with this setup don't have the same problem. Would preclearing drives in a v4.7 box create any problems? I don't believe so. I did experience slow zeroing (step #2 - writing to disk) when attempting to preclear in the v5.0-rc8a box, so I precleared the parity and data drives in a v4.7 box, so maybe this was the first clue of slow write speeds, however when that same data drive is used in the x9SCM-F with v4.7 I get a 20MB/s write speed, which is ok. I tried WinSCP to transfer a 2GB iso file from the WIN7 client to the X9SCM-F/v5.0-rc8a and had the same result ~ 1.2MB/s write speed. testing components include network cards: Intel 82574L (on-board), Intel EXPI9301CT (add-on) SATA controllers: Intel Cougar Point 6 port SATA AHCI Controller (on-board) tried multiple 6Gb and 3Gb ports, SAS2LP-MV8 (add-on) clients: WIN7, XPSP3 I'm out of ideas at the moment.

I checked the Ethernet adapter in the WIN7 client and flow control was already enabled.

I installed v4.7 on the x9scm-f and got a 20 MB/s write speed from the WIN7 client. This is similar setup as the previous few tests with v5.0-rc8a, no parity, v1.1a bios on x9, EXPI9301CT 1GB adapter, x9 on-board SATA controller for (1) data drive. I wonder why the disparity in write speed between v4.7 and v5.0-rc8a. If I use the v5.0-rc8a AIO file and add my existing pro key file, that is the correct way to start a new v5.0-rc8a server, right?

I only have one WIN7 client with a 1Gb connection and that is where I am copying from. I do have another XPSP3 client (but with a 100Mb NIC) and it's also getting the slow write speed ~ 1.2 MB/s. From the WIN7 client, I can write the same 1GB test file to my other unRAID server (v4.7 in my sig) at ~ 19 MB/s (w/parity), so the client and LAN don't seem to be the problem. I'm considering replacing v5.0-rc8a with v4.7 on the flash drive in the x9scm-f box and seeing if that has any difference.

I can confirm that this process works. I just successfully downgraded my x9scm-f from bios v2.0a to bios v1.1a. The command to downgrade to from v2.0a to v1.1a bios is "afudosu x9scm1.928 /p /b /n /r /k /fdt /mer /opr". Note that the "x9scm1.928" text is the v1.1a ROM file. The Supermicro instructions (link in OP) omit the ROM file in the command. I appended the "/fdt /mer /op" at the end of the command line since I was unsure if I should run the second step without the other options "/p /b /n /r /k".