September 29, 200817 yr ... dmesg | grep "md: xor" ... This number really shou;ld be in teh GUI somewhere as its a prime component of uNRAID operation.
September 29, 200817 yr "vmstat" is in UnRaid server 4.3.3? I can try it. Yes, I believe it is. You can also do this command: dmesg | grep "md: xor" And it will tell you how fast your CPU calculates the XOR function (used for parity calcs). On my single core AMD Athlon, it says: "md: xor using function: p5_mmx (8824.400 MB/sec)." That is over 8 gigabytes per second. Even giving an order of magnitude allowance for overhead, that is still 800 megabytes per second. That would let you copy a 5 GB DVD is under 10 seconds. So the CPU could keep up with that rate, but obviously a disk can not. My single core Athlon XP 3.2+ gives me approx. 6668.800 (6894.00 after booting with 6.4b1) on that, what speed is your single core?
September 29, 200817 yr acpitool -e CPU type : AMD Athlon 64 Processor 3700+ Min/Max frequency : 1000/2400 MHz Current frequency : 2400 MHz Frequency governor : performance Freq. scaling driver : powernow-k8 Cache size : 1024 KB Bogomips : 4825.68
September 29, 200817 yr ... dmesg | grep "md: xor" ... This number really shou;ld be in teh GUI somewhere as its a prime component of uNRAID operation. It is quite meaningless... having it in the GUI would tell you nothing... As already said, the CPU is much-much faster that the disk I/O. It is in the syslog too: root@Tower:/# grep xor /var/log/syslog Sep 9 13:32:41 Tower kernel: md: xor using function: pIII_sse (3698.000 MB/sec) As you can see, it is still WAY faster than the disks, even on the original Intel IDE motherboard in the MD1200. Joe L.
September 29, 200817 yr This number really shou;ld be in teh GUI somewhere as its a prime component of uNRAID operation. Well, it is a 'bragging' number, but as the others have said above, it makes little difference in unRAID operation. The XOR speed is so much faster than the disk I/O speed, that I don't think a significantly faster XOR speed would even be detectable. I've thought about mentioning in the past how much faster the nVidia NForce chipsets (typically 8000's) are than the Intel chipsets (typically 4 to 6000's), at least in XOR processing speeds, but apart from bragging rights, it did not make any operational difference. If you are using Unmenu, the syslog viewer highlights the XOR line in green (should be blue, as a system number). I thought about highlighting the BogoMIPS number(s), but couldn't think of any significance that it has for unRAID operation. If anyone can tell me that a significantly better BogoMIPS number would make a detectable difference in unRAID operation, then I'll be happy to highlight it too.
September 29, 200817 yr I set up a simple test system... only two drives. Each is a 250GB WD. Hdparm tests give about 51MB/sec for each drive. Then I started a parity check. Parity check is running at 44MB/sec. In top, unraidd is only using 8% of the CPU. Mpstat (over a 20 second average) says: CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s Average: all 0.00 0.00 9.43 0.00 1.15 0.00 0.00 89.43 304.69 So the CPU is 89.4% idle while calculating parity.
September 29, 200817 yr No dual core I should have specified I'm running the old school system (aka home built 1500) Installed fine with a parity check in progress. Are you running a dual-core CPU? Also looks like its time to add a 4.4 to the forum and maybe consolidate some of the older 4.x folders together. Yes, we'll do that soon.
September 29, 200817 yr What matters with Parity calculation is 1. drive bandwidth 2. controller bandwidth 3. bus bandwidth Not necessarily in that order. This weekend I increased the number of drives and controllers. but my parity calculation went down because I maxed out the number of drives on the ICH controller. I went from 60,000MB/s down to 40,000MB/s because of the increase on that controller. I did also add 2 more drives, however they are on different controllers. 6WD green drives on board - ICH controller 2 Seagate 7200RPM/32MB cache drives on SIL3132 controller in PCIe X1 slot 1 Seagage 7200RPM/32MB cache drive on SIL3132 controller onboard (PCIe X1). When I watch the drive activty, the WD drives are solid as if they are reaching max read speeds The Seagates are flickering/toggling as if they are being read and the other drives are slowing them down. During basic tests of hdparm and dd, the segates are at least 30MB/s faster then the WD's So there's allot more to the parity calculation then CPU, CPU in today's world being the least of the issue. My Norco DS-520G with a celeron-M 1ghz gets a slightly higher parity calculation speed with 5 7200RPM maxtor drives.
September 29, 200817 yr To visit the other end of the spectrum where SMP can make a huge difference, I use my unRAID server for downloads, and par2/unraring of the downloads. When repairing with par files or unraring, the CPU will max out. I also batch transcode video files, which will take several hours, also maxing out the CPU. These functions are greatly enhanced by SMP. In the middle ground, user interfaces (such as the unRAID managment) can be "snappier" with the extra power of SMP, but not always as the thing that boggs them down can still be disk, and not CPU. So if all your unRAID box does is serve up files, SMP won't make much difference. If you put other applications on it, or run a virtual machine environment, SMP will benefit you.
September 29, 200817 yr I set up a simple test system... only two drives. Each is a 250GB WD. Hdparm tests give about 51MB/sec for each drive. Then I started a parity check. Parity check is running at 44MB/sec. In top, unraid is only using 8% of the CPU. Mpstat (over a 20 second average) says: CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s Average: all 0.00 0.00 9.43 0.00 1.15 0.00 0.00 89.43 304.69 So the CPU is 89.4% idle while calculating parity. When version 4.0 was originally released I did a similar test, but instead of seeing how well the CPU did with a parity check, I did it while reconstructing a replaced drive AND serving up ISO images that were on the drive being replaced. (they would have to be read from the other drives and calculated) The post is here: http://lime-technology.com/forum/index.php?topic=578.msg3754#msg3754 Basically, 5 separate sets of xor calculations, and the CPU was 70% idle. The disks were pretty busy, the "waiting on I/O" showed it was spending 16% of the time waiting for responses from the disks. As already said, SMP capability in this new version of unRAID will do little or nothing to increase parity calc spped. Joe L.
September 29, 200817 yr Does this release revert to the previous means of spinning down hard disks or is it the same as 4.3.3.? Although unraid-notify script solved all my issues with spun down, I am very much interested in this as well.
September 29, 200817 yr dmesg | grep "md: xor" Return me: root@Tower:~# dmesg | grep "md: xor" md: xor using function: pII_mmx (5723.600 MB/sec)
September 29, 200817 yr Q6600 quad here.... boots without a hiccup, everything seems okay so far... as a plus, the "usual" Abit AB9pro ACPI errors in the syslog are conspicuous in their absence syslog attached
September 29, 200817 yr Author Q6600 quad here.... boots without a hiccup, everything seems okay so far... as a plus, the "usual" Abit AB9pro ACPI errors in the syslog are conspicuous in their absence syslog attached The syslog looks perfect! Good report!
September 29, 200817 yr Author Does this release revert to the previous means of spinning down hard disks or is it the same as 4.3.3.? Although unraid-notify script solved all my issues with spun down, I am very much interested in this as well. This will be coming in a future -beta. The only changes between 4.4-beta1 and 4.3.3 are those detailed in the release readme.txt file. This is done on purpose in order to reduce the number of code changes which need to be examined if/when users report bugs.
September 29, 200817 yr Tom, can you update Smartcontrol in the next release? The current 5.36 does not run tests correctly on my Seagate 1 tb drives
September 29, 200817 yr I'd also really really really like an implementation of bonjour, so Macs are supported better. My whole setup is Apple based, as I'm sure a few other peoples are as well.
September 29, 200817 yr Author Tom, can you update Smartcontrol in the next release? The current 5.36 does not run tests correctly on my Seagate 1 tb drives Will 5.38 do the job?
September 29, 200817 yr Works cool for me. However there are few little errors such as: Sep 29 22:31:18 Tower kernel: system 00:08: iomem range 0xffe80000-0xffefffff could not be reserved Sep 29 22:31:18 Tower kernel: system 00:08: iomem range 0xffc00000-0xffffffff could not be reserved Sep 29 22:31:18 Tower kernel: Couldn't register serial port 0000:00:03.3: -28 My system: Asus P5E-VM Do bios v.0803 Celeron 420 2 x 512mb kingston BQ! SP 450W 3 x HD501LJ, 1 X 7200.11 750GB, 1 X 7200.10 160GB Now, when SMP is supported, and some drivers got updated i'm waiting for security & reliablity improvements and revamping the web panel. P.S. Is it possible to export Fuse shares via NFS on that kernel? Full syslog here:
September 29, 200817 yr This will be coming in a future -beta. The only changes between 4.4-beta1 and 4.3.3 are those detailed in the release readme.txt file. This is done on purpose in order to reduce the number of code changes which need to be examined if/when users report bugs. Gorgeous! Could you please include some lower inactivity sets as well? (eg 20-30-45 minutes) Thank you!
September 29, 200817 yr Author Works cool for me. However there are few little errors such as: Sep 29 22:31:18 Tower kernel: system 00:08: iomem range 0xffe80000-0xffefffff could not be reserved Sep 29 22:31:18 Tower kernel: system 00:08: iomem range 0xffc00000-0xffffffff could not be reserved Sep 29 22:31:18 Tower kernel: Couldn't register serial port 0000:00:03.3: -28 Those messages are harmless. My system: Asus P5E-VM Do bios v.0803 Celeron 420 2 x 512mb kingston BQ! SP 450W 3 x HD501LJ, 1 X 7200.11 750GB, 1 X 7200.10 160GB Now, when SMP is supported, and some drivers got updated i'm waiting for security & reliablity improvements and revamping the web panel. What driver updates are you referring to? P.S. Is it possible to export Fuse shares via NFS on that kernel? Well as perhaps you know, it 'kinda' works already. But there is more work in this area being done in the 2.6.27 kernel, e.g., refer to: http://thread.gmane.org/gmane.linux.file-systems/23338 At present 2.6.27 is still in 'prepatch' status, refer to: http://kernel.org/ When 2.6.27 gets released as 'latest stable' status, then we'll probably immediately upgrade. If this happens while 4.4 is still in beta, then we'll consider doing the kernel update at that time since this is a highly requested feature.
September 29, 200817 yr Gorgeous! Could you please include some lower inactivity sets as well? (eg 20-30-45 minutes) Thank you! Can You decrese time of inactivity for spin down of HDD?
September 29, 200817 yr Looks good. CPU0: Intel® Core2 Duo CPU E4500 @ 2.20GHz stepping 0d Brought up 2 CPUs CPU: L1 I cache: 32K, L1 D cache: 32K CPU: L2 cache: 2048K Total of 2 processors activated (8802.98 BogoMIPS). md: xor using function: pIII_sse (6604.800 MB/sec) Memory: 3601780k/4194304k available (2101k kernel code, 65980k reserved, 917k data, 204k init, 2751360k highmem) Full syslog attached... (P.S. - I'd also like to see that spindown fixed)
September 30, 200817 yr Upgraded (swapped out bzroot and bzimage), rebooted, got two missing disks (one WD and one Seagate). Did a full power-cycle and same problem. Tried one other reboot. No love. Went back to 4.3 final and all is well. I will try again later after a parity check. I did one a few weeks ago so I didn't feel the need to do it today. Sorry, didn't grab my syslog before my 4.3 recovery. I will update this post regardless, but if I have the same issue I will include the syslog and any other relevant details. Cheers, Bill Update: After a successful parity last night, I got 4.4-beta1 up and running and it appears to activate both CPUs: Sep 29 22:02:30 Tower kernel: CPU0: Intel(R) Pentium(R) D CPU 2.80GHz stepping 07 Sep 29 22:02:30 Tower kernel: APIC calibration not consistent with PM Timer: 109ms instead of 100ms Sep 29 22:02:30 Tower kernel: APIC delta adjusted to PM-Timer: 937034 (1030729) Sep 29 22:02:30 Tower kernel: Booting processor 1/1 ip 6000 Sep 29 22:02:30 Tower kernel: Initializing CPU#1 Sep 29 22:02:30 Tower kernel: Calibrating delay using timer specific routine.. 4198.06 BogoMIPS (lpj=20990334) Sep 29 22:02:30 Tower kernel: CPU: Trace cache: 12K uops, L1 D cache: 16K Sep 29 22:02:30 Tower kernel: CPU: L2 cache: 1024K Sep 29 22:02:30 Tower kernel: CPU: Physical Processor ID: 0 Sep 29 22:02:30 Tower kernel: CPU: Processor Core ID: 1 Sep 29 22:02:30 Tower kernel: Intel machine check architecture supported. Sep 29 22:02:30 Tower kernel: Intel machine check reporting enabled on CPU#1. Sep 29 22:02:30 Tower kernel: CPU1: Intel P4/Xeon Extended MCE MSRs (24) available Sep 29 22:02:30 Tower kernel: x86 PAT enabled: cpu 1, old 0x7040600070406, new 0x7010600070106 Sep 29 22:02:30 Tower kernel: CPU1: Intel(R) Pentium(R) D CPU 2.80GHz stepping 07 Sep 29 22:02:30 Tower kernel: checking TSC synchronization [CPU#0 -> CPU#1]: passed. Sep 29 22:02:30 Tower kernel: Brought up 2 CPUs I also did some real-world measurements (move DVD ISO from/to the unRaid) and found a 9% read improvement and 15% write improvement. My previous measurements were with the 30% performance tweak. Not bad, not bad at all! Bill
Archived
This topic is now archived and is closed to further replies.