Download v4.3.3 from Lime Downloads, extract bzroot and bzimage to your flash drive, and reboot.

 

However, there is one condition.  Since you started with v4.4.2, there is a possibility that your hardware was not fully supported with previous releases.  What motherboard are you using?

Download v4.3.3 from Lime Downloads, extract bzroot and bzimage to your flash drive, and reboot.

 

However, there is one condition.  Since you started with v4.4.2, there is a possibility that your hardware was not fully supported with previous releases.  What motherboard are you using?

 

I have an older board - Intel BOX D975XBX2.  I am pretty sure my board would be supported.  The newest thing I have are all the 1.5TB drives.

Not sure if my post here is warranted. But maybe someone can let me know if my speeds seem about right.

 

Unraid 4.4.2

Intel D975XBX2 (using all 8 onboard controllers)

3 Adaptec 1430SA PCI Express controllers. 

 

Cache Drive - ST3500641AS 500GB

Parity Drive - ST31500341AS 1.5TB

15 Drives in Array - ST31500341AS 1.5TB

 

With AHCI turned off (IDE Mode) - parity check at 33MB / Sec

With AHCI turned on - parity check at 38MB / Sec

 

Confirmed all drives are set to NCQ of 1.  (None of my drives are WD - so I did not expect to see that fix work)

 

hdparm test results -

500GB Cache drive - Timing Cache Reads 1760 MB/sec, Timing Buffered Disk Reads = 59 MB/sec

All 1.5 Drives test similar - Timing Cache Reads 1700-1800 MB/sec, Timing Buffered Disk Reads = 120-128 MB/sec

 

I am posting my information - because at one time  I was getting 80-100MB / Sec parity check (my first build using Super Micro board and only 7 1.5 TB drives)  I did expect a drop off in performance with a maxed out array - but is 38MB/Sec parity check about right?

 

When transfering files to the array - (no cache drive) - I get about 8mb / sec to some drives and 12mb / sec to other drives.

 

Any tips?  Or are these results to be expected?

 

This seems slow to me.  I have 15 drives (14 data + parity) on my P5B VM DO (motherboard + 2 1430SA).  I get 50-60 MB/sec speeds on parity checks.  Several of my disks are the older WD GP drives and older Seagates (7200.10) with lower densities.  I would not expect that you'd be slower than me with those drives.  (Not that 38 MB/sec is bad, just that I don't understand why it is that speed and not faster).

 

I would suggest that you boot 4.3.3 and compare your results.

 

General note - the changing of the queue_depth may have some minor impact on my READ performance. but the SEVERE slowdowns are only present on WRITES.

 

I am a little raw when it comes to unraid -  do I need to do anything special to revert to 4.3.3?  I first started with 4.4.2.   

 

Ok - quick update.

 

I downgraded to 4.3.3.

 

Parity check runs all over the place.  Initially it was as high as 75MB/sec but quickly dropped down to 20MB/sec.  I let it run for a few hours and while 4.4.2 ran at a steady 37-38MB/sec.  Version 4.3.3. seems to jump all over the place.  Ranging from 20MB-44MB/sec.  (I never did see that high initial burst of speed.

 

I tested file transfers and they all seems slightly faster.  But nothing to write home about.  With 4.4.2 some drives would be at about 8mb sec and others as fast as 12MB.  Version 4.3.3 seems to be pretty steady across all the drives.  I am seeing 10-14MB/sec transfers.

 

I wish I knew what happened to all that speed I saw when I built my first system.....

I have been ignoring this issuing, hoping it might be fixed in the linux kernel update; apparently it wasn't.  unRAID does not 'tweak' the disk drivers in any way (maybe it should though, see below).

 

I remember early on (like a couple years ago), AHCI was very problematic & not all controllers supported it, so I always configure this 'off' in the bios.  In addition, I believe that NCQ in linux is only implemented in the AHCI driver (could be wrong on that), hence I don't have much specific performance testing with AHCI/NCQ.

 

Anyway, one reason I haven't been much interested in NCQ is because it probably will not increase performance at all, and instead if anything, might decrease performance or add instability.  This is because the linux disk drivers are already highly optimized for ordering seeks.  By the time commands are sent down to the disk, the internal NCQ algorithm probably could not improve the order further.  Especially in media server application where large files are access, NCQ will certainly make no difference.

 

NCQ, like queue reordering in SCSI, is mainly a meaningless feature precisely because the host O.S. driver is so much better at re-ordering the queue.  (Who are you going to trust to write better queuing code: kernel developers or hard drive firmware coders - no offense to any hard drive firmware coders reading this - but you know I'm right 

 

NCQ, like queue reordering in SCSI makes sense if you have one hard disk being accessed asynchronously by two different computers - not bloody likely, and certainly not in SATA.  Historical note: NCQ is the evil step-child of SCSI tagged command queuing.  Tagged commands are necessary in SCSI because of the bus nature of SCSI (ie, multiple devices that share the same physical bus).  After finally getting multiple target code right, disk firmware designers noticed that tagged commands could be used to manage internal disk queues, and hey, those kernel developers don't know how to write proper queuing code, so what the heck, let's write it ourselves.  Then when the marketing folks discovered that this new-fangled mult-task O.S. (Windows) does perform better with disk-side queue management (because the hard drive firmware guys could write better queuing code than the windows guys), the myth of NCQ was born!

 

So... probably upon system startup I'll just set queue_depth to 1 on all devices and restore proper performance 

Who are you going to trust to write better queuing code: kernel developers or hard drive firmware coders

 

Depends on which kernel you are talking about.  Windows kernel or Linux?  ;D

So... probably upon system startup I'll just set queue_depth to 1 on all devices and restore proper performance 

 

I am leaving mine setup that way.

 

It's good to know that this is not some hardware or incompatibility problem related to my configuration.

So... probably upon system startup I'll just set queue_depth to 1 on all devices and restore proper performance 

 

Tom, to be clear, are you going to add this to a future release, or will it be up to us to muck around in the Go script?  Personally I'd be happier if Unraid just worked this way, but will muck if you say I have to.