I have recently installed Unraid and have been working to get everything setup correctly.  I have been experiencing very slow transfer speeds while I was migrating data to the array.   After some reading on the forum I removed the Parity disks and the write speeds seemed to improve from 2-4Mbit/Sec to 10-13Mbit/sec.   I have recently ran the CA Fix Common Problems tool and the following errors appeared.  It was recommended I post the diagnostics to the forums.   Can anyone please assist?

 

On another note I am trying to run unBALANCE for the first time and it is running at 1Mbit/sec,  slower than any transfers I have had since I started.

diagnostics-20170814-1215.zip

You are using very slow 4 port Sil3114 PCI controllers, all 8 disks will share the 130MB/s available for the PCI bus, you should replace both with a 8 port PCIe controller, LSI recommended.

 

Also, your onboard controller is in IDE mode, change it to AHCI, better performance for the SSDs (beside IDE mode won't even support trim).

Thanks.   Will the new LSI solve the Call Traces and IRQ 18 issues being reported?

 

Would this card work fine?

 

https://www.amazon.com/SAS9211-8I-8PORT-Int-Sata-Pcie/dp/B002RL8I7M

 

Thanks for the help!

4 minutes ago, chalk4 said:

Will the new LSI solve the Call Traces and IRQ 18 issues being reported?

 

Possibly, look also for a board bios update and there are reports of these being fixed by booting using UEFI (only supported on v6.4rc), BTW both IRQ 17 and 18 are being disabled.

 

6 minutes ago, chalk4 said:

Would this card work fine?

 

Yes

59 minutes ago, johnnie.black said:

BTW both IRQ 17 and 18 are being disabled.

Good catch.  Updating FCP to support multiple IRQ's being disabled.  ty

Sorry for my ignorance.   What are IRQ 17 and 18 used for and why would they be disabled?

reboot and right after that type on the console:

 

cat /proc/interrupts

 

In your case, IRQ 17 & 18 were both used for the PCI sata controllers.

 

IRQ stands for Interrupt ReQuest

 

Basically an OS (any OS) tells your controllers, "hey can you grab this data for me".   When the IRQ is active, the controller responds with "Sure thing buddy, I'll let you know when I've got it".  When the data is ready, the controller Interrupts whatever is going on and send the data.

 

Without the Interrupt being active,  the controller responds with "Ok.  Check back later when you have some time"  At some point in the future, the OS checks back, and the data may or may not be there waiting for it.  If its there then everything is good, if its not, then the OS proceeds to continue to execute whatever other applicication happens to be running at the time and then eventually gets around to checking for it again.

 

Net result is that if an IRQ gets disabled, the whole process is significantly slower (as you're seeing)

 

 

Why it gets disabled, I'm not entirely sure.

 

Side note:

 

Many motherboard manuals (at least for the ones I've ever bought) show you on the expansion slots which slots share which interrupts with other slots.  In a perfect world, you want to try and isolate cards from each other's interrupts (or at least think about what you don't care about on a collision.  IE:  My use case dictates that I pretty much never have USB3 ports actually in use, therefore I don't care about if the interrupts the motherboard shares with them collide with a particular slot).

 

And the command that @johnnie.black listed is logged in the syslog when FCP finds that an IRQ has been disabled to assist him and others in figuring out if its actually a problem or not.

3 minutes ago, Squid said:

And the command that @johnnie.black listed is logged in the syslog when FCP finds that an IRQ has been disabled to assist him and others in figuring out if its actually a problem or not.

 

That's good that FCP logs that, didn't know and hadn't checked the syslog that far, with the controllers getting their IRQ disable it's no wonder you're having terrible performance, much worse than would already have because of them being older PCI controllers.

Well i rebooted and the speeds are sustained at 30+MB/sec.   I have ordered the LSI card and will see if i run into any other issues once i have that installed.   Thanks for the help fellas... much appreciated!

Reboot fixes the IRQ issues but it will probably happen again.

Agreed.  The new LSI should be here in a couple days.  I will just have to deal with the reboots until it is installed.