limetech Posted June 18, 2013 Author Share Posted June 18, 2013 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
jaybee Posted June 18, 2013 Share Posted June 18, 2013 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
dikkiedirk Posted June 18, 2013 Share Posted June 18, 2013 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
dikkiedirk Posted June 18, 2013 Share Posted June 18, 2013 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. Link to comment
Harpz Posted June 18, 2013 Share Posted June 18, 2013 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
dikkiedirk Posted June 18, 2013 Share Posted June 18, 2013 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
Glo8al Posted June 18, 2013 Share Posted June 18, 2013 All working well on my system. The AFP mounts are very slow on OSX 10.8.4, but did read that else where. Thx Link to comment
dikkiedirk Posted June 18, 2013 Share Posted June 18, 2013 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. Link to comment
Dephcon Posted June 18, 2013 Share Posted June 18, 2013 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. Link to comment
optiman Posted June 18, 2013 Share Posted June 18, 2013 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
axeman Posted June 18, 2013 Share Posted June 18, 2013 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
StevenD Posted June 18, 2013 Share Posted June 18, 2013 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
jumperalex Posted June 18, 2013 Share Posted June 18, 2013 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
Dephcon Posted June 18, 2013 Share Posted June 18, 2013 yeah can someone re-post the most recent version of that script, I only have 1.5 Link to comment
WeeboTech Posted June 18, 2013 Share Posted June 18, 2013 yeah can someone re-post the most recent version of that script, I only have 1.5 I will soon. (in another thread). Link to comment
optiman Posted June 18, 2013 Share Posted June 18, 2013 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 Link to comment
S80_UK Posted June 18, 2013 Share Posted June 18, 2013 RC15 all good for me. Hardware as per sig. Parity check and read write speeds normal. Link to comment
Donovan Posted June 20, 2013 Share Posted June 20, 2013 RC15a is out. http://lime-technology.com/forum/index.php?topic=28087.0 Link to comment
Recommended Posts