June 18, 201313 yr Author 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?
June 18, 201313 yr 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.
June 18, 201313 yr 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?
June 18, 201313 yr Found it, and increased it to 892. Its a bit faster, but nowhere near the speeds I had before. Perhaps I have to find the optimum. What is save? I'm still only running unmenu.
June 18, 201313 yr 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.
June 18, 201313 yr 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.
June 18, 201313 yr All working well on my system. The AFP mounts are very slow on OSX 10.8.4, but did read that else where. Thx
June 18, 201313 yr I'm slowly losing my marbles here. Parity sync speed is dropping to 45. Did hardware support and drivers change for the ARC1200 card? My parity partition is on that card.
June 18, 201313 yr Wowza! I just set sync_window to 1024 and with RC15 I'm getting 110MB/s whihc is a HUGE improvement from RC14, like 60-70MB/s faster.
June 18, 201313 yr 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.
June 18, 201313 yr 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 :-)
June 18, 201313 yr 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?
June 18, 201313 yr 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.
June 18, 201313 yr yeah can someone re-post the most recent version of that script, I only have 1.5 I will soon. (in another thread).
June 18, 201313 yr Parity check completed with the following results, Last checked on Tue Jun 18 08:16:26 2013 PDT (today), finding 0 errors. > Duration: 11 hours, 54 minutes, 31 seconds. Average speed: 70.0 MB/sec
June 18, 201313 yr RC15 all good for me. Hardware as per sig. Parity check and read write speeds normal.
Archived
This topic is now archived and is closed to further replies.