unRAID Server Release 5.0-rc15 Available


Recommended Posts

Unfortunately parity check speed went downhill for me. Where I reached 100+ MB/s at the start in beta12a, I now get about 35 MB/s.

 

I don't know how to improve things, maybe you guys have any tips. I attach a syslog, maybe any of the hardware gurus can tell me what is wrong.

Did you try increasing md_sync_window?

Link to comment
  • Replies 142
  • Created
  • Last Reply

Top Posters In This Topic

Tom knows it said it will be fixed on next version, anyway this is probably caused by some plugin... in the mean time if you want you either downgrade or you can try to disable your plugins and try to identify what one is causing it.

 

It's a plugin issue?

I only have two things I have installed as I have been waiting for 5 to go final before really jumping on board so I am relatively new to it. I have literally only loaded unmenu and simplefatures that I can think of. I have barely got through the installation/configuration guide so there is nothing "hardcore" running at all.

 

I would classify SF as hardcore.. If it's the amount of people that use it, or the complexity of this plugin, but the number of problem threads I've read on this forum which could be traced back to SF is very large in my opinion. Not to discredit the makers ofcourse ;)

 

Just try it without SF and post your results...

 

Oh ok. What about unmenu? I consider having at least one of these two installed as mandatory for my needs in terms of what I would call acceptable levels of control, management and configuration via the webgui.

 

But of course I understand the need to test with nothing installed to help.

Link to comment

Unfortunately parity check speed went downhill for me. Where I reached 100+ MB/s at the start in beta12a, I now get about 35 MB/s.

 

I don't know how to improve things, maybe you guys have any tips. I attach a syslog, maybe any of the hardware gurus can tell me what is wrong.

Did you try increasing md_sync_window?

 

Can you elaborate on that? where is that setting?

 

 

I disabled all plugins and packages and speed increased to about 65 MB/s. Still far from the 100 MB/s I got in earlier betas.

 

I still see this http://lime-technology.com/forum/index.php?topic=27802.0  creeping in, maybe it has something to do with it?

Link to comment

I disabled all plugins and packages and speed increased to about 65 MB/s.

 

A 30 MB/s jump is quite an improvement, I wonder if others would see such improvements if the addons/plugins were all removed.

 

I so wish unraid had an interface as polished a SF/Unmenu and default plugin set IE: UPS and clean power down support.

 

There would be no real need to install any of these extras if not needed.

 

It would make problem solving so much easier out the box, no screwing about with which version of the plugin you have etc etc.

Link to comment

Unfortunately parity check speed went downhill for me. Where I reached 100+ MB/s at the start in beta12a, I now get about 35 MB/s.

 

I don't know how to improve things, maybe you guys have any tips. I attach a syslog, maybe any of the hardware gurus can tell me what is wrong.

Did you try increasing md_sync_window?

 

Increasing this value only gives a temporary jump in parity check speed to close to 90 MB/s with a value of 1024. When the stalled CPU messages start to appear it drops to 65 MB/s.

Link to comment

Unfortunately parity check speed went downhill for me. Where I reached 100+ MB/s at the start in beta12a, I now get about 35 MB/s.

 

I don't know how to improve things, maybe you guys have any tips. I attach a syslog, maybe any of the hardware gurus can tell me what is wrong.

Did you try increasing md_sync_window?

 

Increasing this value only gives a temporary jump in parity check speed to close to 90 MB/s with a value of 1024. When the stalled CPU messages start to appear it drops to 65 MB/s.

 

Just upgraded to rc15, no issues at all so far.  webgui is more responsive and hasn't timed out at all.  Stopped, rebooted, poweredown, all without any issues.  Nice!

 

A few RC's back, somebody recommended adding a zero to all three of those settings.  I know it was to improve performance, but not sure if I still need them set this high.  That said, speeds seem to be good for my setup.

 

md_num_stripes = 12800

md_write_limit = 7680

md_sync_window = 3840

 

Parity check running now, getting around 90 MB/s, and is almost complete.

 

Link to comment

Unfortunately parity check speed went downhill for me. Where I reached 100+ MB/s at the start in beta12a, I now get about 35 MB/s.

 

I don't know how to improve things, maybe you guys have any tips. I attach a syslog, maybe any of the hardware gurus can tell me what is wrong.

Did you try increasing md_sync_window?

 

Increasing this value only gives a temporary jump in parity check speed to close to 90 MB/s with a value of 1024. When the stalled CPU messages start to appear it drops to 65 MB/s.

 

Just upgraded to rc15, no issues at all so far.  webgui is more responsive and hasn't timed out at all.  Stopped, rebooted, poweredown, all without any issues.  Nice!

 

A few RC's back, somebody recommended adding a zero to all three of those settings.  I know it was to improve performance, but not sure if I still need them set this high.  That said, speeds seem to be good for my setup.

 

md_num_stripes = 12800

md_write_limit = 7680

md_sync_window = 3840

 

Parity check running now, getting around 90 MB/s, and is almost complete.

 

how can we find optimum values for this, is it a trial and error type thing?

 

ooh wise devs. that write add-ons, get us an add-on that tests and reports back best suggested for each scenario :-)

Link to comment

Unfortunately parity check speed went downhill for me. Where I reached 100+ MB/s at the start in beta12a, I now get about 35 MB/s.

 

I don't know how to improve things, maybe you guys have any tips. I attach a syslog, maybe any of the hardware gurus can tell me what is wrong.

Did you try increasing md_sync_window?

 

Increasing this value only gives a temporary jump in parity check speed to close to 90 MB/s with a value of 1024. When the stalled CPU messages start to appear it drops to 65 MB/s.

 

Just upgraded to rc15, no issues at all so far.  webgui is more responsive and hasn't timed out at all.  Stopped, rebooted, poweredown, all without any issues.  Nice!

 

A few RC's back, somebody recommended adding a zero to all three of those settings.  I know it was to improve performance, but not sure if I still need them set this high.  That said, speeds seem to be good for my setup.

 

md_num_stripes = 12800

md_write_limit = 7680

md_sync_window = 3840

 

Parity check running now, getting around 90 MB/s, and is almost complete.

 

 

I did that, on Rc-12a I think, and I had constant hangs.  Is there a "standard" for what these should be set based on the physical RAM available?

Link to comment

I guess the first question is what activity is most impacted by those settings.  Typically the discussion revolves about parity checks.  And I know Tom has described in the past how this value deals with how many reads (writes?) are grouped together and sent to the controller.  While it is nice to improve parity checks (read: reads only), I also want to know what is best for writing to the array.  You know, the thing you do way more often than massive parallel reads, and that you do in real time all the time and not once a month at night (ok the mover puts array writes at night too i know).

 

So ... There were some scripts written by Weebo and [that guy] meant to test array read/writes to each disc individually and also en masse.  Perhaps those scripts, testing read and write speeds with escalating values of md-sync-window would be better tests than timing the first 1-2% of a parity check.  And perhaps that itself could be scripted?  Of course *I* don't have those skills, but i have ideas :)

 

Obviously this might be better in a different thread.  I leave it to the mods to do as they see fit.  Sorry.

Link to comment
Guest
This topic is now closed to further replies.