February 26, 201313 yr 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.
February 26, 201313 yr 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..
February 26, 201313 yr 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...
February 28, 201313 yr 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.
February 28, 201313 yr With the 16gig on board it does not help in the performance issue, is saw improvement on 4gb though.
February 28, 201313 yr 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?
March 2, 201313 yr Ogi... This would be great. I am pretty comfortable with bash, but I have no clue how to troubleshoot hardware issues.
March 2, 201313 yr 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.
March 3, 201313 yr 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.
March 4, 201313 yr 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.
March 5, 201313 yr 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.
March 7, 201313 yr 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.
March 7, 201313 yr 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.
March 8, 201313 yr 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.
March 8, 201313 yr 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 !
March 8, 201313 yr 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)?
March 8, 201313 yr 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 !
March 8, 201313 yr 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.
March 8, 201313 yr 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?
March 8, 201313 yr 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.
March 8, 201313 yr 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.
March 12, 201313 yr 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.
March 12, 201313 yr 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!).
Archived
This topic is now archived and is closed to further replies.