X9SCM-F slow write speed, good read speed

[PeterB]

modprobe powernow-k8

 

Does powernow-k8 do anything for an Intel processor?

 

Are you loading acpi-cpufreq?

 

echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 400 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

 

I'm wondering how you alighted on these particular settings.  I do wonder whether you are just preventing the governor from reducing the clock speed at all.

[Helmonder]

To be perfectly honoust I have absolutely no idea... I started to think that cpu speed might be an issue so I searched around in the forums and found this.. I would be most interested to see if these settings make other people happy to, if so, it might help to find a more structural solution..

[Frank1940]

To be perfectly honoust I have absolutely no idea... I started to think that cpu speed might be an issue so I searched around in the forums and found this.. I would be most interested to see if these settings make other people happy to, if so, it might help to find a more structural solution..

 

Well, I googled "cpufreq/ondemand/up_threshold" and  found these sites (among many others):

 

  http://www.pantz.org/software/cpufreq/usingcpufreqonlinux.html

                                        and

  https://wiki.archlinux.org/index.php/CPU_Frequency_Scaling

                                        and

  http://www.ivanlam.info/blog/2011/10/10/linux-cpu-frequency-ondemand-governor-settings/

 

These give some clues as to what may be happening.  If the CPU is frequency is being reduced with the objective of saving power, exactly what conditions are necessary to ramp it backup?  Interesting...

[Interstellar]

modprobe powernow-k8

 

Does powernow-k8 do anything for an Intel processor?

 

Are you loading acpi-cpufreq?

 

echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 400 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

 

I'm wondering how you alighted on these particular settings.  I do wonder whether you are just preventing the governor from reducing the clock speed at all.

 

 

I have mine set to 20 and 500 respecively and my server goes down to min clocks. Provides the best performance too.

[Helmonder]

With the 16gig on board it does not help in the performance issue, is saw improvement on 4gb though.

[ogi]

I'm wondering if there is some kind of BASH script that we (X9SCM-F owners) can run to help Tom diagnose this issue.  I'm not a BASH/linux expert my any stretch of the imagination, but if we can provide him with consistent measurable results/logs, perhaps that will help?

[whiteatom]

Ogi... This would be great. I am pretty comfortable with bash, but I have no clue how to troubleshoot hardware issues.

[Helmonder]

I will be doing a nice test next week. I will replace my i3 2120T with a Xenon 1203 v1. A more powerfull processor and other structure, the rest of the system will remain the same, pretty curious what will be the result on this and other stuff.

[JimmyJoe]

Just ran into this problem myself after I upgraded.

 

Old Hardware:

Motherboard - SuperMicro C2SEA - 6 sata ports

CPU - Intel Pentium Dual-Core E5200 Processor, 2.5 GHz, 2M L2 Cache, 800MHz FSB, LGA775

Power Supply - CORSAIR 750w TX Series 80 Plus Certified Power Supply

Memory - CORSAIR XMS3 4GB (2 x 2GB) 240-Pin DDR3 1333 TW3X4G1333C9

Controller - Qty 2 - Adaptec 1430SA PCIe x4 - 8 ports (4 each)

Controller - Qty 1 - SD-SA2PEX-2IR PCIe x1 - 2 ports (Sil3132 chipset)

Controller - Qty 1 - LSI PCI SATA MegaRAID 150-6 Kit - 6 ports

 

New Hardware:

Motherboard: Supermicro X9SCM-IIF-O bios 2.0a

CPU: Intel Xeon E3-1220 Sandy Bridge

Power Supply: CORSAIR HX750

Memory: 32GB - 4x Super Talent DDR3-1333 8GB ECC Micron

Controller: 2x IBM M1015 w/P15 IT Mode (used for unRAID)

Controller: 1x IBM M1015 w/P15 IR Mode (installed but unused, future use for ESXi)

 

Write speeds went down to ~1MB/s for any writes to disks, including dd copies between disks (with no parity).  I set mem=4095 and all my writes went back up to normal, ~70 MB/s.

[PeterB]

New Hardware:

Motherboard: Supermicro X9SCM-IIF-O bios 2.0a

CPU: Intel Xeon E3-1220 Sandy Bridge

Power Supply: CORSAIR HX750

Memory: 32GB - 4x Super Talent DDR3-1333 8GB ECC Micron

Controller: 2x IBM M1015 w/P15 IT Mode (used for unRAID)

Controller: 1x IBM M1015 w/P15 IR Mode (installed but unused, future use for ESXi)

 

Write speeds went down to ~1MB/s for any writes to disks, including dd copies between disks (with no parity).  I set mem=4095 and all my writes went back up to normal, ~70 MB/s.

 

Interesting that this is similar to my configuration, except I only have 8GB ram, a 1230V2 (previously a Sandy Bridge 1230) and different SATA controllers, and I don't discern any problems.

[Helmonder]

I just upgraded my setup to a 1230 but first time I booted without the MEM= parameter and started a copy I got a kernel panic; "lack of memory and no processes to kill". Am now running with the MEM= parameter and the dirtable parameter and all seems to be fine again.

[Helmonder]

And still all is fine, plenty of memory, good speeds and no oom. Life is bliss.

[mr.sparkle]

Does cache_dirs suffer from having to limit the RAM?

[Helmonder]

No... actually the 4gb limit has only made my system more stable and more performing. This means:

 

1) The >4gb causes issues

2) There is no need to have more then 4GB.

[JonathanM]

No... actually the 4gb limit has only made my system more stable and more performing. This means:

 

1) The >4gb causes issues

2) There is no need to have more then 4GB.

This applies to probably 80% or more of users. However... I and several others are running virtualbox, and each virtual machine takes a chunk of ram. My 8GB system still on 4.7 would be crippled if I had to reduce to 4GB, as my currently running VM's are allocated over 4GB in total. I suppose I could build a whole new machine and run ESXI, but my current system is fine, the only sticking point is lack of 3TB support with 4.7. So... I will be waiting to upgrade, probably until the 64 bit version is released, which at the current rate will probably be 2014.

[limetech]

A couple experiments to try.  Please use a completely "stock" configurations, i.e., no plugins, no memory limit, stock 'go' file, etc.

 

Experiment #1:

 

Go to Settings/Disk Settings and change these parameters:

 

md_num_stripes: 4096

md_write_limit: 2048

 

Stop and then Start the array for changes to take effect.  Please let me know if there is any difference in write transfer rate to an array disk.

 

Experiment #2:

 

(This will invalidate your parity, so only try this on a test array, or an array where you won't mind rebuilding the parity afterwards.)

 

Stop array and unassign the parity disk.  Start array, see if slow write persists.

[Helmonder]

Hi Tom,

 

I changed my parity disk to a new disk a week ago, that would be the same test as you are describing, it did not solve anything for me. I'll certainly change the settings and test !

[limetech]

Hi Tom,

 

I changed my parity disk to a new disk a week ago, that would be the same test as you are describing, it did not solve anything for me. I'll certainly change the settings and test !

Did you try writes before assigning you new parity disk (that is, while array was unprotected)?

[Helmonder]

Note: I tried without disabling plugins (could not resist trying but do not have the immediate time to disable them, will do this weekend).

 

These tests done with the different tunables, array has been stopped and started to activate:

 

- Without MEM parameter and without dirtyable speed is approx 500K/sec

- Without MEM parameter and with dirtyable speed is 50MB/Sec which is really fast.

 

So there definately is some effect !

[Helmonder]

Hi Tom,

 

I changed my parity disk to a new disk a week ago, that would be the same test as you are describing, it did not solve anything for me. I'll certainly change the settings and test !

Did you try writes before assigning you new parity disk (that is, while array was unprotected)?

 

Sorry, no, I did not...my bad, I responded to quickly.

[jowi]

I just upgraded my setup to a 1230

I'm interested in your experience with this Xeon cpu. I'm currently using the Intel 2120T like you had before, and yesterday i noticed that during playback of a high bitrate bluray scene, the display started stuttering. The reason for this was that at that moment, sabnzbd was actually joining the parts of a 12GB file it just downloaded. So, apparently that was too much for the cpu to handle. I wonder if the Xeon could handle things like this?

[Helmonder]

What you experienced is not a cpu issue, if you check cpu stats you will see it is not peaking at all. It  is more an issue with disk access and easily solved by setting an option in sabnzbd:

 

setup - options - queue - tick "stop downloading while unpacking" (or something like that).

 

That will solve your issue.

[jowi]

I dont think so. Sab was not downloading, download was finished en sab was joining downloaded files while unraid was sharing a bluray... but i will look in to it.

[Frank1940]

A couple experiments to try.  Please use a completely "stock" configurations, i.e., no plugins, no memory limit, stock 'go' file, etc.

 

Experiment #1:

 

Go to Settings/Disk Settings and change these parameters:

 

md_num_stripes: 4096

md_write_limit: 2048

 

Stop and then Start the array for changes to take effect.  Please let me know if there is any difference in write transfer rate to an array disk.

 

Experiment #2:

 

(This will invalidate your parity, so only try this on a test array, or an array where you won't mind rebuilding the parity afterwards.)

 

Stop array and unassign the parity disk.  Start array, see if slow write persists.

 

Twenty-four pages of complaints, comments and suggestions.  A couple of suggested band-aid solutions.  Tom requests that users who have said they had a problem conduct two experiments to see if the parameters used in the unRAID code might be contributing to this issue.  After five days, only one person tries one of his ideas.  Apparently, this is not much of an issue at this point...      Perhaps, version 5 should be released without a full resolution to the problem.   

[ogi]

A couple experiments to try.  Please use a completely "stock" configurations, i.e., no plugins, no memory limit, stock 'go' file, etc.

 

Experiment #1:

 

Go to Settings/Disk Settings and change these parameters:

 

md_num_stripes: 4096

md_write_limit: 2048

 

Stop and then Start the array for changes to take effect.  Please let me know if there is any difference in write transfer rate to an array disk.

 

Experiment #2:

 

(This will invalidate your parity, so only try this on a test array, or an array where you won't mind rebuilding the parity afterwards.)

 

Stop array and unassign the parity disk.  Start array, see if slow write persists.

 

Twenty-four pages of complaints, comments and suggestions.  A couple of suggested band-aid solutions.  Tom requests that users who have said they had a problem conduct two experiments to see if the parameters used in the unRAID code might be contributing to this issue.  After five days, only one person tries one of his ideas.  Apparently, this is not much of an issue at this point...      Perhaps, version 5 should be released without a full resolution to the problem.   

 

Would totally be doing this check, but I'm still trying to recover my array from having several disks overheat, and some file system corruption issues, and so on and so forth (it's taken the better part of the week, and I'm still not done!).