AVS-10/4 Now Available to Order

[Harpz]

hehe,

No idea why but I'm quite excited / looking forward to the upcoming rc13 and v5 final even though I have zero issues with the 12a i currently running.

 

Guess its the anticipation of what's coming i don't know lol.

[PeterB]

Or, now that we're PAST the projected RC13 release date ...

 

Yep, it's Monday, June 3 here|

[Dougy]

tom #1 has responded briefly that he is working on it....  while this is the best communication we would ever expect from tom #1, what about tom #2.  He showed up, made the announcements about the new releases and also said his role was to b) provide more regular updates (yeah, I know this has been a big issue for many of you).

 

Tom #2 time to provide an update. 

[garycase]

Tom #2 time to provide an update.

 

+1

 

... although it's only been a couple days since the last update.  Even if we just get one update/week that would be a HUGE improvement over the past !!

 

[theone]

Don't forget it is/was the weekend...

 

[graywolf]

tom #1 has responded briefly that he is working on it....  while this is the best communication we would ever expect from tom #1, what about tom #2.  He showed up, made the announcements about the new releases and also said his role was to b) provide more regular updates (yeah, I know this has been a big issue for many of you).

 

Tom #2 time to provide an update.

 

Considering it is 2pm Sunday, most likely won't get an updated status until later on Monday.

 

Unless of course you are expecting Tom #1 & Tom #2 to work 24x7.

 

[tyrindor]

tom #1 has responded briefly that he is working on it....  while this is the best communication we would ever expect from tom #1, what about tom #2.  He showed up, made the announcements about the new releases and also said his role was to b) provide more regular updates (yeah, I know this has been a big issue for many of you).

 

Tom #2 time to provide an update.

 

Considering it is 2pm Sunday, most likely won't get an updated status until later on Monday.

 

Unless of course you are expecting Tom #1 & Tom #2 to work 24x7.

 

If I set a deadline to people who bought my software, and then continuously did not meet that deadline, hired a new person to help meet deadlines, set a new deadline, still did not meet it... You better believe i'd be working 24/7 to please people who bought my software. You'd also better believe if I didn't meet the deadline I wouldn't vanish. Not to mention it's been in beta for over a year (Almost 2?). It's time to sit down, and get the job done. I've never seen any non-abandonware software sit in RC status for almost a year... or has it been over a year? It's been so long I forget.

 

I am one of the people that actually has issues with RC12a, i've posted threads (and so have others) of the SAS2LP parity check speed issues plaguing unRAID after Beta 12a (Beta, not RC). We've had something like 12 releases since then and it has never been fixed/acknowledge/etc. Now the new unRAID servers use SASLP cards, not the newer SAS2LP cards. So does that mean we're just screwed? *shrug*

[limetech]

...

I am one of the people that actually has issues with RC12a, i've posted threads (and so have others) of the SAS2LP parity check speed issues plaguing unRAID after Beta 12a (Beta, not RC). We've had something like 12 releases since then and it has never been fixed/acknowledge/etc. Now the new unRAID servers use SASLP cards, not the newer SAS2LP cards. So does that mean we're just screwed? *shrug*

 

I have that specific card on order and will be able to try and duplicate this issue when it comes in this coming week.  It uses PCI-E x8 slot, which not all m/b's support correctly, though you'd think Supermicro would & since I also have your same m/b I should be able to get to the bottom of it.

[mrow]

 

...

I am one of the people that actually has issues with RC12a, i've posted threads (and so have others) of the SAS2LP parity check speed issues plaguing unRAID after Beta 12a (Beta, not RC). We've had something like 12 releases since then and it has never been fixed/acknowledge/etc. Now the new unRAID servers use SASLP cards, not the newer SAS2LP cards. So does that mean we're just screwed? *shrug*

 

I have that specific card on order and will be able to try and duplicate this issue when it comes in this coming week.  It uses PCI-E x8 slot, which not all m/b's support correctly, though you'd think Supermicro would & since I also have your same m/b I should be able to get to the bottom of it.

 

 

Any update on the ETA of RC13?

[Pauven]

I have that specific card on order and will be able to try and duplicate this issue when it comes in this coming week.  It uses PCI-E x8 slot, which not all m/b's support correctly, though you'd think Supermicro would & since I also have your same m/b I should be able to get to the bottom of it.

 

Tom, thank you for taking a look at the parity check issues with the SAS2LP.  I have some relevant info, and since the forum is such a large place, I'm sure my post went unnoticed by your eyes.

 

I have a HighPoint 2760A, which is notable in that it uses the same Marvel 88SE9485 SAS/SATA controller chip as the SAS2LP, the same mvsas driver, and in that I am experiencing the exact same parity check performance issue.

 

My first awareness of the issue in my brand new build:  http://lime-technology.com/forum/index.php?topic=27460.msg242873#msg242873

 

My verification that the 2760A was connecting at PCIe 2.0 x16:  http://lime-technology.com/forum/index.php?topic=27460.msg243813#msg243813

 

dskt.sh test results showing controller achieves max throughput:  http://lime-technology.com/forum/index.php?topic=27460.msg244049#msg244049

 

My conclusion of the source of the issue:  http://lime-technology.com/forum/index.php?topic=27460.msg244334#msg244334

 

All of the links are from the same thread, so you could just read through from the first link.  There's other nuggets of info in that thread that I didn't specifically link to, which may be of interest to you.

 

Please let me know if I may be of assistance.

 

-Paul

[limetech]

Tom, thank you for taking a look at the parity check issues with the SAS2LP.  I have some relevant info, and since the forum is such a large place, I'm sure my post went unnoticed by your eyes.

...

 

Please let me know if I may be of assistance.

 

-Paul

Did you try adjusting the "tunables" on the 'Settings/Disk Settings' page?

 

Here are the default values:

 

md_num_stripes = 1280

md_write_limit = 768

md_sync_window = 384

 

It might help to increase 'md_sync_window' to 512 or 768 or higher, just don't exceed 'md_num_stripes'.  You can increase 'md_num_stripes' too depending on how much memory you want to allocate (each increment to 'md_num_stripes' requires roughly 4K per drive in the array).

 

What 'md_sync_window' defines is the number of 4K requests the unraid driver can queue up to the underlying disk driver.  Things get complicated because the disk driver tries to consolidate these small requests and send down a smaller number of larger requests to the actual disk.

 

What I have found in the past is that increasing 'md_sync_window' does indeed increase parity sync performance until you get to some value where increasing it has diminishing returns.

 

Another tunable that might affect this is "Force NCQ disabled".  The default is to disable NCQ (native command queuing).  This is because in the past performance was better with NCQ turned off, but I haven't looked at this for a long time and maybe drivers and HDD's have implemented this better and it's time to turn NCQ back on.

[limetech]

Any update on the ETA of RC13?

Just finished testing everything I wanted to get into -rc13, so it will be tomorrow (or rather later today - Monday).

[NAS]

Excellent news. People can gear up ready to do some testing.

 

Nice work

[mrow]

Any update on the ETA of RC13?

Just finished testing everything I wanted to get into -rc13, so it will be tomorrow (or rather later today - Monday).

 

 

Great news! Cant wait to load it up and take it for a spin.

 

BetaQuasi, get ready to make a new vmdk!

[garycase]

Tom, thank you for taking a look at the parity check issues with the SAS2LP.  I have some relevant info, and since the forum is such a large place, I'm sure my post went unnoticed by your eyes.

...

 

Please let me know if I may be of assistance.

 

-Paul

Did you try adjusting the "tunables" on the 'Settings/Disk Settings' page?

 

Here are the default values:

 

md_num_stripes = 1280

md_write_limit = 768

md_sync_window = 384

 

It might help to increase 'md_sync_window' to 512 or 768 or higher, just don't exceed 'md_num_stripes'.  You can increase 'md_num_stripes' too depending on how much memory you want to allocate (each increment to 'md_num_stripes' requires roughly 4K per drive in the array).

 

What 'md_sync_window' defines is the number of 4K requests the unraid driver can queue up to the underlying disk driver.  Things get complicated because the disk driver tries to consolidate these small requests and send down a smaller number of larger requests to the actual disk.

 

What I have found in the past is that increasing 'md_sync_window' does indeed increase parity sync performance until you get to some value where increasing it has diminishing returns.

 

Another tunable that might affect this is "Force NCQ disabled".  The default is to disable NCQ (native command queuing).  This is because in the past performance was better with NCQ turned off, but I haven't looked at this for a long time and maybe drivers and HDD's have implemented this better and it's time to turn NCQ back on.

 

Tom,

Did you notice the major differential between a disk rebuild and a parity check in Pauven's testing?    [in this post:  http://lime-technology.com/forum/index.php?topic=27460.msg244334#msg244334 ]

 

1/3rd longer to do a parity check rather than a disk rebuild ... which conceptually should require almost an identical set of disk I/O's, except the disk being rebuilt will be written instead of read.  In fact, if anything, it would seem the rebuild should take fractionally longer, since in the parity check case all I/O can be done at the same time; whereas in the rebuild case all the reads have to be done before the corresponding write can be done.

 

Are there different values used for the tunable parameters in a rebuild?    If so, that would seem to be a good starting point for adjusting the values.

 

[spylex]

...

I am one of the people that actually has issues with RC12a, i've posted threads (and so have others) of the SAS2LP parity check speed issues plaguing unRAID after Beta 12a (Beta, not RC). We've had something like 12 releases since then and it has never been fixed/acknowledge/etc. Now the new unRAID servers use SASLP cards, not the newer SAS2LP cards. So does that mean we're just screwed? *shrug*

 

I have that specific card on order and will be able to try and duplicate this issue when it comes in this coming week.  It uses PCI-E x8 slot, which not all m/b's support correctly, though you'd think Supermicro would & since I also have your same m/b I should be able to get to the bottom of it.

 

I would also like to see progress/status on this. I have both SASLP and SAS2LP and the newer card suffers heavily.

[garycase]

I have that specific card on order and will be able to try and duplicate this issue when it comes in this coming week.  It uses PCI-E x8 slot, which not all m/b's support correctly, though you'd think Supermicro would & since I also have your same m/b I should be able to get to the bottom of it.

 

Excellent.  It would be great to have this resolved.  Not only for the SAS2LP, but also for the 2760a Highpoint 24-port card that uses the same chips (and has the same issue).

 

[nars]

Another tunable that might affect this is "Force NCQ disabled".  The default is to disable NCQ (native command queuing).  This is because in the past performance was better with NCQ turned off, but I haven't looked at this for a long time and maybe drivers and HDD's have implemented this better and it's time to turn NCQ back on.

 

I did tested it recently on my modest server and it was worst when NCQ on.

[johnodon]

- unRAID v5.0-rc13 will be available for download later this week...

 

[nars]

johnodon: not sure if you noticed there was an update:

 

Any update on the ETA of RC13?

Just finished testing everything I wanted to get into -rc13, so it will be tomorrow (or rather later today - Monday).

[johnodon]

johnodon: not sure if you noticed there was an update:

 

Any update on the ETA of RC13?

Just finished testing everything I wanted to get into -rc13, so it will be tomorrow (or rather later today - Monday).

 

Ahhh...missed that.  Thx.

 

John

[Pauven]

Did you try adjusting the "tunables" on the 'Settings/Disk Settings' page?

 

No, I've never touched these  before.  I will go ahead and test, just need some clarification below.  Thank you.

 

(each increment to 'md_num_stripes' requires roughly 4K per drive in the array).

What is an increment?  Is 384 to 512 an increment or 128 increments? 

 

If 128 increments, then going from 384 to 512 on a 16 drive server will use an additional 8MB?

 

Do I need to increase to specific intervals (by 128, by powers of 2, by 8, etc.) or to specific targets (384, 512, 768 only)?

 

Another tunable that might affect this is "Force NCQ disabled".  The default is to disable NCQ (native command queuing).  This is because in the past performance was better with NCQ turned off, but I haven't looked at this for a long time and maybe drivers and HDD's have implemented this better and it's time to turn NCQ back on.

 

Testing now, thanks.

[Pauven]

Another tunable that might affect this is "Force NCQ disabled".  The default is to disable NCQ (native command queuing).  This is because in the past performance was better with NCQ turned off, but I haven't looked at this for a long time and maybe drivers and HDD's have implemented this better and it's time to turn NCQ back on.

 

Tom,

 

I've conducted the test 3 times now, switching back and forth between Force NCQ Disabled, and rebooting after each change.

 

Each time I let the Parity Check NOCORRECT run until exactly 1.0% complete (measured on an unMenu screen that does not show any SMART data), then immediately stop it, and measure the elapsed time in the log.  Obviously not a full-scale test, but should be representative of the impact of the change.  After we've tweaked a few more settings to hone in on a good configuration, I'll run a 100% parity check.

 

I'm getting approximately 10% shorter times with NCQ ON (not disabled).  This is a step in the right direction, though I would expect that this may have a similar result during a rebuild.  IF NCQ improves rebuild speed by 10%, then the 30% speed gap during rebuild and parity checks would remain.

 

I have one last 3TB drive waiting in the wings to upgrade one of my 1.5TB drives.  After we've gone through all the tweaks and tests on the parity check speed, and settled on a correct configuration, I will do a rebuild to upgrade and see how the changes affected the rebuild speed.

[garycase]

In another thread, someone tried the NCQ on/off test with a SAS2LP-MV8 and had somewhat contradictory results (it made the times a bit worse) ... but I don't know if their test conditions were as rigid as yours typically are.

 

In any event, have you also tried bumping up the md_num_stripes to perhaps 512?  In the absence of Tom's confirmation, I'm pretty sure you're correct that an increment is a count of 1, so bumping it to 512 will require 8MB for 16 drives ... a moderately large bump in the buffer, so it may indeed help a bit.  It's still perplexing, however, that the rebuilds don't suffer from the same issue !!  I'd think that the same parameters would apply to them as well -- and should have an almost identical impact !!

 

... Part of me hopes you do NOT get this completely resolved -- 'cause it's likely to cost me $600 if you do  8)

[NAS]

Time to fork this discussion into a new thread if you want to continue