garycase Posted October 1, 2015 Share Posted October 1, 2015 is it possible that upgrading from 6.1.2 to 6.1.3 slows down my parity check? my old parity checks are between 85-90MB/s but my last parity check speed is 65MB/s. This is very frustrating. Just updated my oldest server to v6.1.3 and it very notably degraded parity check times. Just before doing the upgrade, ran a parity check on v5.0.6 => took 8:05:42. Reformated the flash drive to a clean v6.1.3, booted and added the drives, and did a parity check => took 10:34:04 ... over 30% longer !! System is an old SuperMicro C2SEA with a dual-core Pentium E6300, 4GB of RAM, and a 14 drive mix of 1.5TB Seagates (4) and 2TB WD Greens. Just for grins, I reverted to v5, booted, and ran another parity check ... which just finished in 8:05 (same as before). I was never on an earlier v6, so I don't know for sure, but based on the quoted issue this worked fine on 6.1.2 (and presumably earlier v6 versions) ... so hopefully 6.1.4 will resolve this I'm inclined to just leave the system on v5 for now, and upgrade it again when v6.1.4 comes out. Quote Link to comment
rick.p Posted October 1, 2015 Share Posted October 1, 2015 same, on 6.1 a check, 29tb server, took 9 hours, 6.1.3 it's been at it 13 hours already and STILl says 1 hour to go Quote Link to comment
garycase Posted October 1, 2015 Share Posted October 1, 2015 Clearly SOMETHING was changed in 6.1.3 that's causing this -- hopefully 6.1.4 will restore the performance that's been lost. Quote Link to comment
Hoopster Posted October 1, 2015 Share Posted October 1, 2015 I don't think the problem is necessarily due to the 6.1.3 release specifically. I ran a parity check with prior versions of 6.x.x and they always took about 7:45:00 to complete. This is more or less the same time a version 5 parity check took on my hardware. I just ran the first parity check since upgrading to version 6.1.3 and it finished in 7:49:00. Four minutes more is not enough for me to say that version 6.1.3 has a problem. Perhaps with your hardware configuration version 6.1.x is slower than 5.x, but, in my case, I have noted little to no difference between version 5 or any version 6 release of unRAID. It may be that some change in 6.1.x with certain hardware or driver combinations does have a negative impact on parity checks; however, it does not appear to be a blanket issue that universally applies to all instances of unRAID 6.1.3. EDIT: actually I remembered incorrectly the parity check time in version 6.1.3, I just checked the main page and it finished in 7:47:15, about two minutes more than "normal" at an average speed of a little over 107 MB/s Quote Link to comment
garycase Posted October 1, 2015 Share Posted October 1, 2015 I suspect the difference is that something in 6.1.3 is far more CPU-intensive ... and thus a parity check doesn't have enough "horsepower". But if it had enough for v5, v6.1.1, and v6.1.2, I have to wonder what's changed in 6.1.3 that increases the CPU demands enough to cause a 30% drop in parity check performance (in my case) and even more in some others. Quote Link to comment
garycase Posted October 1, 2015 Share Posted October 1, 2015 ... One thought: Note the discussion about the size of the release starting at Reply #15. I wonder if there was perhaps a bit "too much" trimming ... and that something was removed that in fact DID have an impact on parity check performance (at least on some sets of hardware). The system I upgraded that has this issue uses hardware identical to one of Limetech's mainstay servers of a few years ago [superMicro C2SEA with Adaptec 1430SA controllers] ... so I'd certainly think it's not some outlier in terms of supporting code. Quote Link to comment
ikosa Posted October 1, 2015 Share Posted October 1, 2015 I suspect the difference is that something in 6.1.3 is far more CPU-intensive ... and thus a parity check doesn't have enough "horsepower". But if it had enough for v5, v6.1.1, and v6.1.2, I have to wonder what's changed in 6.1.3 that increases the CPU demands enough to cause a 30% drop in parity check performance (in my case) and even more in some others. I think the same way, low powered cpus have this issue. When i track both spontaeous speed and cpu utilization, when cpu usage hits 100% speed decreased to 35-40MB/s when speed increases to 70-80MB/s cpu usage decreases to 60-70%. Quote Link to comment
rick.p Posted October 1, 2015 Share Posted October 1, 2015 same, on 6.1 a check, 29tb server, took 9 hours, 6.1.3 it's been at it 13 hours already and STILl says 1 hour to go Finally finished - Duration: 15 hours, 15 minutes, 41 seconds. Average speed: 72.8 MB/sec Quote Link to comment
rick.p Posted October 2, 2015 Share Posted October 2, 2015 I suspect the difference is that something in 6.1.3 is far more CPU-intensive ... and thus a parity check doesn't have enough "horsepower". But if it had enough for v5, v6.1.1, and v6.1.2, I have to wonder what's changed in 6.1.3 that increases the CPU demands enough to cause a 30% drop in parity check performance (in my case) and even more in some others. I think the same way, low powered cpus have this issue. When i track both spontaeous speed and cpu utilization, when cpu usage hits 100% speed decreased to 35-40MB/s when speed increases to 70-80MB/s cpu usage decreases to 60-70%. AMD A6-6400K APU , was watching it during the check and the CPU on both cores never got above 40% Quote Link to comment
RobJ Posted October 2, 2015 Share Posted October 2, 2015 Here are the firmware files trimmed from 6.1.3 (folder names are in brackets). If you want detail of what's in a particular folder, just ask. For example, in adaptec are 2 small files of 832 bytes, starfire_tx.bin and starfire_rx.bin, and in mrvl is just sd8787_uapsta.bin. I personally think it's unlikely any of these are needed or applicable, but you are welcome to examine the list for yourself. [.] [..] 3CCFEM556.cis [3com] 3CXEM556.cis [acenic] [adaptec] [advansys] agere_ap_fw.bin agere_sta_fw.bin [ar3k] ar7010.fw ar7010_1_1.fw ar9170-1.fw ar9170-2.fw ar9271.fw ath3k-1.fw [ath6k] atmsar11.fw [av7110] BCM2033-FW.bin BCM2033-MD.hex bnx2x-e1-4.8.53.0.fw bnx2x-e1-5.2.13.0.fw bnx2x-e1-5.2.7.0.fw bnx2x-e1h-4.8.53.0.fw bnx2x-e1h-5.2.13.0.fw bnx2x-e1h-5.2.7.0.fw [brcm] [cis] COMpad2.cis COMpad4.cis [cpia2] [cxgb3] [cxgb4] [dabusb] DP83903.cis [dsp56k] dvb-fe-xc5000-1.6.114.fw dvb-usb-dib0700-1.20.fw dvb-usb-terratec-h5-drxk.fw E-CARD.cis [edgeport] [emi26] [emi62] [ene-ub6250] [ess] f2255usb.bin htc_7010.fw htc_9271.fw i2400m-fw-usb-1.4.sbcf i2400m-fw-usb-1.5.sbcf i6050-fw-usb-1.5.sbcf intelliport2.bin ipw2100-1.3-i.fw ipw2100-1.3-p.fw ipw2100-1.3.fw ipw2200-bss.fw ipw2200-ibss.fw ipw2200-sniffer.fw iwlwifi-100-5.ucode iwlwifi-1000-3.ucode iwlwifi-1000-5.ucode iwlwifi-105-6.ucode iwlwifi-135-6.ucode iwlwifi-2000-6.ucode iwlwifi-2030-6.ucode iwlwifi-3945-2.ucode iwlwifi-4965-2.ucode iwlwifi-5000-1.ucode iwlwifi-5000-2.ucode iwlwifi-5000-5.ucode iwlwifi-5150-2.ucode iwlwifi-6000-4.ucode iwlwifi-6000g2a-5.ucode iwlwifi-6000g2b-5.ucode iwlwifi-6000g2b-6.ucode iwlwifi-6050-4.ucode iwlwifi-6050-5.ucode [kaweth] [keyspan] [keyspan_pda] [korg] LA-PCM.cis lbtf_usb.bin lgs8g75.fw [libertas] [matrox] [mrvl] MT5634ZLX.cis mts_cdma.fw mts_edge.fw mts_gsm.fw mts_mt9234mu.fw mts_mt9234zba.fw [mwl8k] [myricom] NE2K.cis [ositech] PCMLM28.cis PE-200.cis PE520.cis phanfw.bin ql2100_fw.bin ql2200_fw.bin ql2300_fw.bin ql2322_fw.bin ql2400_fw.bin ql2500_fw.bin [qlogic] [r128] [radeon] RS-COM-2P.cis rt2561.bin rt2561s.bin rt2661.bin rt2860.bin rt2870.bin rt3070.bin rt3071.bin rt3090.bin rt3290.bin rt73.bin [RTL8192E] [rtlwifi] s2250.fw s2250_loader.fw [sb16] [slicoss] STLC2500_R4_00_03.ptc STLC2500_R4_00_06.ssf STLC2500_R4_02_02_WLAN.ssf STLC2500_R4_02_04.ptc [sun] [sxg] tamarack.cis TDA7706_OM_v2.5.1_boot.txt TDA7706_OM_v3.0.2_boot.txt [tehuti] [ti-connectivity] ti_3410.fw ti_5052.fw tlg2300_firmware.bin tr_smctr.bin [ttusb-budget] [ueagle-atm] [usbdux] usbduxfast_firmware.bin usbduxsigma_firmware.bin usbdux_firmware.bin v4l-cx231xx-avcore-01.fw v4l-cx23418-apu.fw v4l-cx23418-cpu.fw v4l-cx23418-dig.fw v4l-cx23885-avcore-01.fw v4l-cx23885-enc.fw v4l-cx25840.fw [vicam] vntwusb.fw [vxge] whiteheat.fw whiteheat_loader.fw [yam] [yamaha] [zd1211] I can't help feeling we are jumping to conclusions without sufficient data points yet. We need to hear more comparative speeds, with which version they were run under, and an assurance it was the same hardware. Quote Link to comment
garycase Posted October 2, 2015 Share Posted October 2, 2015 same, on 6.1 a check, 29tb server, took 9 hours, 6.1.3 it's been at it 13 hours already and STILl says 1 hour to go Finally finished - Duration: 15 hours, 15 minutes, 41 seconds. Average speed: 72.8 MB/sec Wow => that's a 69% increase in the time for a parity check !! And I thought my 30+% was bad. ... VERY interesting that your CPU wasn't pegging either !! ["... was watching it during the check and the CPU on both cores never got above 40% ...] Quote Link to comment
trurl Posted October 2, 2015 Share Posted October 2, 2015 Haven't posted on the 6.1.3 thread yet, just thought I would report that it doesn't seem to have any significant impact on my parity check speeds. 6TB parity - Duration: 14 hours, 45 minutes, 51 seconds. Average speed: 112.9 MB/sec Quote Link to comment
garycase Posted October 2, 2015 Share Posted October 2, 2015 ... I can't help feeling we are jumping to conclusions without sufficient data points yet. We need to hear more comparative speeds, with which version they were run under, and an assurance it was the same hardware. As near as I can tell, all of the reported speed differences are on IDENTICAL hardware with nothing different except the UnRAID version. At least in my case, that's absolutely true. My v5 system had nothing "extra" running except the APC and Clean Powerdown utilities. It normally runs cache_dirs, but that was disabled for the parity check. The v6 install had only the Clean Powerdown Plugin (since UPS support is built in). Absolutely nothing else. What I find particularly interesting is that according to others this was NOT an issue with 6.1.1 or 6.1.2 => only with 6.1.3. I have no idea whether any of the "stuff" trimmed for v6.3 had any impact on this -- I suspect that's likely not the case. But SOMETHING changed ... with a result that's not good. I assume Limetech can replicate my issue, since a SuperMicro C2SEA with Adaptec 1430SA was the configuration of their "mainstream" server for quite a while. Quote Link to comment
garycase Posted October 2, 2015 Share Posted October 2, 2015 Haven't posted on the 6.1.3 thread yet, just thought I would report that it doesn't seem to have any significant impact on my parity check speeds. 6TB parity - Duration: 14 hours, 45 minutes, 51 seconds. Average speed: 112.9 MB/sec Wouldn't expect any notable impact with an i5-4570S (PassMark 6620) ... that's got plenty of extra "headroom". Quote Link to comment
archedraft Posted October 2, 2015 Share Posted October 2, 2015 My parity check seems to be running around the same, maybe slightly slower but then again I'm using an i7. That said has anyone noticed the web GUI being very sluggish with this release? I've tried clearing the history but that only resolves it for a bit and then it goes really slow at switched tabs again. Quote Link to comment
BRiT Posted October 2, 2015 Share Posted October 2, 2015 My parity check is roughly the same as it's ever been. unRAID Parity check: 2015-10-01 11:32 Notice [***] - Parity check finished (0 errors) Duration: 8 hours, 31 minutes, 59 seconds Average speed: 130.2 MB/sec Quote Link to comment
Hoopster Posted October 2, 2015 Share Posted October 2, 2015 That said has anyone noticed the web GUI being very sluggish with this release? I've tried clearing the history but that only resolves it for a bit and then it goes really slow at switched tabs again. Yes, I have noticed the same. Sometime it can take 7-8 seconds to switch between tabs. At other times, there is no lag. This just started happening for me with version 6.1.3. Prior versions switched tabs without lag. That said, others have reported slow tab switching in prior versions as well. In my case the slow switching is *always* from the Docker tab to another tab. Switching to the docker tab is not a problem, but, if it is going to be slow it is always from Docker tab to Main, Shares, Users, etc. Quote Link to comment
bonienl Posted October 2, 2015 Share Posted October 2, 2015 Clearly SOMETHING was changed in 6.1.3 that's causing this -- hopefully 6.1.4 will restore the performance that's been lost. I keep a record of all my parity check speeds since version 6.0 and in my case there isn't any noticable diffierence between unRAID versions (it varies between 10h17m and 10h22m). Whatever it is, it isn't impacting everyone... Quote Link to comment
bonienl Posted October 2, 2015 Share Posted October 2, 2015 My parity check seems to be running around the same, maybe slightly slower but then again I'm using an i7. That said has anyone noticed the web GUI being very sluggish with this release? I've tried clearing the history but that only resolves it for a bit and then it goes really slow at switched tabs again. Can you be more precise about the pages where this is observed? I don't have any sluggish-net myself apart from the VMs page which sometimes takes a bit longer to load. Quote Link to comment
MyKroFt Posted October 2, 2015 Share Posted October 2, 2015 Duration: 14 hours, 43 minutes, 52 seconds. Average speed: 75.4 MB/sec 38TB parity check - same for me as in previous versions Myk Quote Link to comment
Squid Posted October 2, 2015 Share Posted October 2, 2015 That said has anyone noticed the web GUI being very sluggish with this release? I've tried clearing the history but that only resolves it for a bit and then it goes really slow at switched tabs again. Yes, I have noticed the same. Sometime it can take 7-8 seconds to switch between tabs. At other times, there is no lag. This just started happening for me with version 6.1.3. Prior versions switched tabs without lag. That said, others have reported slow tab switching in prior versions as well. In my case the slow switching is *always* from the Docker tab to another tab. Switching to the docker tab is not a problem, but, if it is going to be slow it is always from Docker tab to Main, Shares, Users, etc. Does this only happen if you go into the docker tab and then quickly go out of it to another tab? If you let it sit on the docker tab for say 10 seconds, is switching out of the tab quick? Quote Link to comment
Squid Posted October 2, 2015 Share Posted October 2, 2015 Duration: 14 hours, 43 minutes, 52 seconds. Average speed: 75.4 MB/sec 38TB parity check - same for me as in previous versions Myk If anything, 6.1.3 increased my speed by a good margin on my SAS2LP controller. Shaved an hour off of the parity check times and brought me back to the times that I had before the pre-emptible kernel was introduced in 6.0b14d. Quote Link to comment
Hoopster Posted October 2, 2015 Share Posted October 2, 2015 That said has anyone noticed the web GUI being very sluggish with this release? I've tried clearing the history but that only resolves it for a bit and then it goes really slow at switched tabs again. Yes, I have noticed the same. Sometime it can take 7-8 seconds to switch between tabs. At other times, there is no lag. This just started happening for me with version 6.1.3. Prior versions switched tabs without lag. That said, others have reported slow tab switching in prior versions as well. In my case the slow switching is *always* from the Docker tab to another tab. Switching to the docker tab is not a problem, but, if it is going to be slow it is always from Docker tab to Main, Shares, Users, etc. Does this only happen if you go into the docker tab and then quickly go out of it to another tab? If you let it sit on the docker tab for say 10 seconds, is switching out of the tab quick? Interesting observation. The slow switching from docker to another tab is more likely to occur on fast switches between tabs (e.g. less than 10 seconds on docker tab before switching to another); however, it sometimes is slow to switch to another tab even after a couple of minutes on the docker tab. I will say it is much less likely to occur if the docker tab has been open a while. Again, in my case (100% repeatable thus far), slow switching only happens from docker to another tab and never between any other tabs. Quote Link to comment
bonienl Posted October 2, 2015 Share Posted October 2, 2015 That said has anyone noticed the web GUI being very sluggish with this release? I've tried clearing the history but that only resolves it for a bit and then it goes really slow at switched tabs again. Yes, I have noticed the same. Sometime it can take 7-8 seconds to switch between tabs. At other times, there is no lag. This just started happening for me with version 6.1.3. Prior versions switched tabs without lag. That said, others have reported slow tab switching in prior versions as well. In my case the slow switching is *always* from the Docker tab to another tab. Switching to the docker tab is not a problem, but, if it is going to be slow it is always from Docker tab to Main, Shares, Users, etc. Does this only happen if you go into the docker tab and then quickly go out of it to another tab? If you let it sit on the docker tab for say 10 seconds, is switching out of the tab quick? Interesting observation. The slow switching from docker to another tab is more likely to occur on fast switches between tabs (e.g. less than 10 seconds on docker tab before switching to another); however, it sometimes is slow to switch to another tab even after a couple of minutes on the docker tab. I will say it is much less likely to occur if the docker tab has been open a while. Again, in my case (100% repeatable thus far), slow switching only happens from docker to another tab and never between any other tabs. CA loads quite a lengthy table of all available dockers and this may be causing the delay you are witnessing. The browser needs to store and clear all this information upon entering and leaving the page. You may want to test this to see if it makes a difference in your case. Quote Link to comment
Squid Posted October 2, 2015 Share Posted October 2, 2015 Interesting observation. The slow switching from docker to another tab is more likely to occur on fast switches between tabs (e.g. less than 10 seconds on docker tab before switching to another); however, it sometimes is slow to switch to another tab even after a couple of minutes on the docker tab. I will say it is much less likely to occur if the docker tab has been open a while. Again, in my case (100% repeatable thus far), slow switching only happens from docker to another tab and never between any other tabs. Then let me try the magic ball again... Ignoring that it sometimes happens after sitting on the tab for a while, the quick switches that are consistently slow can be explained away like this: Your internet is either slow or consistently maxed out, and you also are running Community Applications. Basically what happens with the docker tab when CA is installed is that CA automatically downloads an updated list of the apps available (~70k download). You can see that this is in progress if the spinning ring is still displayed on the CA tab. Until that process is finished, getting out of the tab can be slow. (On my pretty average internet speeds, it usually is done in ~1/2 second if nothing else is happening with regards to downloads, or ~5 seconds if my connection is maxed out). Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.