X9SCM-F slow write speed, good read speed

[moose]

It should be about the same. Compare the completion times.

 

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

[dgaschk]

It looks like php is enabled in BIOS. See link in my sig.

[moose]

It looks like php is enabled in BIOS. See link in my sig.

 

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

[ptmuldoon]

It looks like php is enabled in BIOS. See link in my sig.

 

Can you clarify what you mean by indicating php is enabled in the Bios?  I played with the php programming language.  Are you referring to the same thing?  Also, please note the X9SCM Bios has a lot of different looks than the Intel D865GLCLK, so its difficult trying to compare/find the same settings.

[dgaschk]

I meant PnP. Not php. Damn autocorrect.

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

[bcbgboy13]

Try disabling the "aggressive link power management" and "hot plug" capabilities on the two hard drives.

[limetech]

I found this discussion on gmane.org:

http://comments.gmane.org/gmane.linux.kernel/1372917

 

Someone in that thread created a page for that M/B 

https://sites.google.com/a/lucidpixels.com/web/blog/supermicrox9scm-fissues

 

He doesn't talk about "slow disk write".

 

Maybe try installing no more than 16GB RAM as a test.

 

But here's what's very odd about this problem:

- parity sync seems to run more-or-less as expected, at least not the huge slowdown with ordinary writes.  This is odd because the unRaid driver just issues normal write requests down to the disk drivers.

- writes to cache disk are slow too, and this I/O completely bypasses the unRaid driver, so seems like the issue isn't there

- seems to work on the older linux kernel used in 5.0-rc5 (which is 3.0.35).  This would point to a kernel/driver issue.  It's unrealistic for me to revert back to the 3.0.x kernel for unRaid, however.

[Helmonder]

I found this discussion on gmane.org:

http://comments.gmane.org/gmane.linux.kernel/1372917

 

Someone in that thread created a page for that M/B 

https://sites.google.com/a/lucidpixels.com/web/blog/supermicrox9scm-fissues

 

He doesn't talk about "slow disk write".

 

Maybe try installing no more than 16GB RAM as a test.

 

But here's what's very odd about this problem:

- parity sync seems to run more-or-less as expected, at least not the huge slowdown with ordinary writes.  This is odd because the unRaid driver just issues normal write requests down to the disk drivers.

- writes to cache disk are slow too, and this I/O completely bypasses the unRaid driver, so seems like the issue isn't there

- seems to work on the older linux kernel used in 5.0-rc5 (which is 3.0.35).  This would point to a kernel/driver issue.  It's unrealistic for me to revert back to the 3.0.x kernel for unRaid, however.

 

I have 16Gig installed in my system, currently I am getting 620 KB/s. A preclear is also running though, that might do something.

 

Reverting back does not sound good no, the system is not unusable to me in its present state, only reason I notice it is that I am moving large amounts of files between drives at the moment (implementing a different storage strategy in an attempt to get even lower power consumption).

 

Are there any more tests I can do to assist in finding the issue ?

 

To me it really sounds like a kernal issue.. I do not understand the reference to samba though, I am getting these speeds while copying disk-to-disk in a telnet session.. So samba should not be envolved right ? The same goes for the info on the page concerning network nic's, I cannot imagine that beiing an issue while doing in-server copying..

[downloadski]

Moose asked me to test.

 

I3 2100T X9SCM-F 16 GB of memory.

Bios v2.0a

1 TB Hitachi Rev B cache drive

 

test is copy speed from PC to the cached volume

 

With 5.0-rc6-r8168-test:

48.540.999.680 bytes in 14:48 (52 MByte/sec average)

(this is a blu ray rip with files maximum of 4 GB in size)

 

with 5.0 RC8:

34.053.918.720 bytes in 11:57 (45 Mbyte/sec average)

(this s a blu ray rip with 1 * 29 GB file and some smaller files)

 

Test done with teracopy and i see with smaller files the speed up to 72 Mbyte/sec and with > 4 GB files between 40-55 Mbyte/sec.

[WizADSL]

This is a complete shot in the dark, but could you try turning off hyper-threading in the bios and see if that makes any difference?

[Helmonder]

I found this discussion on gmane.org:

http://comments.gmane.org/gmane.linux.kernel/1372917

 

Someone in that thread created a page for that M/B 

https://sites.google.com/a/lucidpixels.com/web/blog/supermicrox9scm-fissues

 

He doesn't talk about "slow disk write".

 

Maybe try installing no more than 16GB RAM as a test.

 

But here's what's very odd about this problem:

- parity sync seems to run more-or-less as expected, at least not the huge slowdown with ordinary writes.  This is odd because the unRaid driver just issues normal write requests down to the disk drivers.

- writes to cache disk are slow too, and this I/O completely bypasses the unRaid driver, so seems like the issue isn't there

- seems to work on the older linux kernel used in 5.0-rc5 (which is 3.0.35).  This would point to a kernel/driver issue.  It's unrealistic for me to revert back to the 3.0.x kernel for unRaid, however.

 

My transfers were dropping to 400 to 500 KB/s, I decided to some "just to be sure" testing. I have restarted the system with unaid V5b5 instead of rc8a. Transfers are now indeed around 15 MB/s again while copying with MC from disk to disk in a telnet session.

 

I have setup my flashdrive so that I can easily switch between both RC's and will use b5 for large scale copying (only do this once in a blue moon, so not so much of an issue)

[ptmuldoon]

 

I have setup my flashdrive so that I can easily switch between both RC's and will use b5 for large scale copying (only do this once in a blue moon, so not so much of an issue)

 

What/how did you do your flash drive to make it easier to switch between versions?  I'd like to continue trying to help and experiment with Bios settings, etc, but now that I have my Pro.Key and more than 3 drives in the system, I do not want to be changing flash drives.

 

I also wonder if Limetech may consider upgrading the kernel again.  I believe the big change in rc5 to rc8a was going from kernel 3.0 to 3.4  But I believe there is a new 3.6 kernel released back in September.

 

EDIT..  I actually just had another thought.  Does anyone know of another simple linux distro with kernel 3.4 on it to test write speeds on?  It may help to determine if its Kernel related or not.

 

 

[moose]

 

I have setup my flashdrive so that I can easily switch between both RC's and will use b5 for large scale copying (only do this once in a blue moon, so not so much of an issue)

 

What/how did you do your flash drive to make it easier to switch between versions?  I'd like to continue trying to help and experiment with Bios settings, etc, but now that I have my Pro.Key and more than 3 drives in the system, I do not want to be changing flash drives.

 

I also wonder if Limetech may consider upgrading the kernel again.  I believe the big change in rc5 to rc8a was going from kernel 3.0 to 3.4  But I believe there is a new 3.6 kernel released back in September.

 

EDIT..  I actually just had another thought.  Does anyone know of another simple linux distro with kernel 3.4 on it to test write speeds on?  It may help to determine if its Kernel related or not.

 

I had the same thought today...about some other 3.4.11 distro to test. 

 

I understand Tom not wanting to go back to an earlier kernel especially since 3.4.11 fixed other outstanding issues.

 

I'm just wondering why some X9SCM-F users have problems and others (more) don't, especially since the X9SCM-F seems like a fairly popular MB...could be a couple of reasons:

 

• X9SCM-F users haven't upgraded to 5.0-rc8a yet.
  
• X9SCM-F users have upgraded to 5.0-rc8a but haven't written large files and noticed a problem.
  
• certain X9SCM-F users (like me) have a certain un-agreeable configuration with the MB
  
• certain X9SCM-F users (like me) have a hw/sw defect with the MB
  

 

The X9SCM-F does seem to have various bugs relative to the BIOS.  Other users in the links that Tom pointed out indicate these issues....the [H]ard|Forum site indicates these problems too, but neither indicates anything specific to me that would explain the slow write problem.

 

I'm going to keep troubleshooting and trying some more of the additional suggested resolutions.  I do like the work-around of using 5.0-rc5 (or earlier) files to write and then switch back to 5.0-rc8a.  Helmonder, is there a easy way to keep additional (bzimage and bzroot) files on the flash and rename/move via telnet (to swap between 5.0-rc versions and reboot)?

 

downloadski, just a random guess but since you aren't having any write speed problems, are you using the X9SCM-F IPMI (feature or the IPMI Ethernet port)  Also what MB LAN port or add-on Ethernet adapter are you using?

 

Does this MB have hardware revisions?  I'll see if I can find anything on that.  I know there is a newer version of this board called the X9SCM-IIF, but I'm asking strictly about the X9SCM-F variety.

 

I would also think (hope) this is a temporary problem, otherwise I would need to consider selling this MB and look for a replacement MB.  My gut instinct tells me its a config issue related to the kernel...I like ptmuldoon's idea of finding a stripped down 3.4.11 distro to test.

[dgaschk]

An additional data point.

 

X9SCM-F, 2G RAM, Pentium G620

 

Writing 4GB file to a disk share: 40MB/s

[downloadski]

I have both normal ethernet connections wired. Sometimes the system did not get network connectivity for whatever reason. But i think i have 1 cable that is not reliable, so that could have been the problem. Changed them all out.

 

I use a linksys srw2008 switch, and a intel ct gigabit desktop adapter on my source pc.

[Helmonder]

I basically just put the two image files on my flashdrive for easy copying, a small script to easy copy should be easy but I will be doing very little switching so I did not bother...

 

I see a lot of info on networks, switches and stuff scrolling along. Please note that in my case the slow response is also there when copying on the array itself (telnet, MC), if that is the case with everyone (which I expect) then all searching on the network level can be forgotten.

 

Maybe this triggers something:

 

I have been moving terrabytes around at B5 now at 20 to 40 MB/s speed, now that I have one disk allmost totally filled  up it dropped to around 4 to 5 MB/s first and is not at under the 1 MB/S

 

SO: This is a leap but it looks like that whatever makes the disk writes slower when a disk fills up happens a lot sooner on B8 (eg: constantly)..

 

Tom: Does that trigger something in your mind maybe ?

[limetech]

Tom: Does that trigger something in your mind maybe ?

 

No.  This is going to be a very difficult problem to track down because it's probably related to something in the kernel.

[Helmonder]

Mmm.. There is a newer kernel ?  If you want me to test anything just let me know..  I need two more days for a preclear to finish and I will revert back to 8a.

[Helmonder]

It remains weird though... I'm allmost done filling another drive to the rim and again transfer speeds drop to 100 / 200 KB/s on B5 where it was 20 to 30 MB/S an hour or so before.

[limetech]

'moose' found this clue:

http://thread.gmane.org/gmane.linux.kernel/1311355

 

This is almost certainly the cause of this issue.  Now, how to fix.... I don't know yet.

[Helmonder]

Righto... !  At some point someone will solve it now... Love the cloud & crowd :-)

[dgaschk]

This appears to processor related. I don't have an issue using a G620. There are a number of things to try in BIOS as a temporary fix. 

• Reduce the number of active cores.
  
• Disable Hyper-threading
  
• Reduce the amount of RAM
  

 

I would try with one core enabled, hyper-threading off and 2G RAM. If this works then repeat test with increased values.

 

Here are the 620 specs: http://ark.intel.com/products/53480/Intel-Pentium-Processor-G620-3M-Cache-2_60-GHz

[Helmonder]

First two done, no result. Can you explain why lesser ram would work ??

 

I know that having a lot of RAM will make for a little less low memory which -could- cause problems.. But with all my plugins running without an issue and the result beiing the same with these plugins loaded AND not loaded its hard to believe it is memory related, but I am willing to learn !

[ptmuldoon]

I can't explain why, but I  confirm that lessor ram does work. 

 

Also, if your not aware of it, this board does required unbuffered RAM.  I have 32GB total 4x8GB ECC DDR3 UDIMM Kingston Memory.  In the last hour here, I first booted up with only 8GB memory in 1 slot.    I then started a preclear on a spare smaller 640GB WD drive.  Write speeds are 100+MB/S.

 

I than shutdown and added a 2nd stick for 16GB Memory.  Again, running preclear, received 100+MB/S

 

This is also running unraid as a VM with ESXI and pass through.  I also took some screen shots as well if anyone needs to see them.

 

Also, make sure you are installing your memory in the proper order of:

DIMM2A , DIMM2B, DIMM1A, and DIMM1B

 

I'm about to add a 3rd stick of memory back in to see what happens.

 

EDIT:  With 24GB of Ram, I am still getting could write speeds.

 

Can someone confirm I did upgrade/switch from rc5 to rc8a correctly.  I believe all that is necessary is changing/overwriting the boot/bzimage and boot/bzroot files?  The web GUI say rc8a, but just want to confirm I did really upgrade correctly, and am getting good write speeds with 24GB or ram. 

 

About to put the last stick of memory back in.