unRAID Server release 4.4-beta1 available

[NAS]

...

dmesg | grep "md: xor"

...

 

This number really shou;ld be in teh GUI somewhere as its a prime component of uNRAID operation.

[heffe2001]

"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?

 

[bubbaQ]

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

 

 

[Joe L.]

...

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.

[RobJ]

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.

[bubbaQ]

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.

[erikatcuse]

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.

 

 

[WeeboTech]

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.

 

[bubbaQ]

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.

[Joe L.]

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.

[olympia]

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.

[Ropo]

dmesg | grep "md: xor"

 

Return me:

 

root@Tower:~# dmesg | grep "md: xor"
md: xor using function: pII_mmx (5723.600 MB/sec)

[jimwhite]

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

 

[limetech]

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!

[limetech]

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.

[NAS]

Sounds good to me. Thanks for clearing it up

[jimwhite]

Tom, can you update Smartcontrol in the next release?  The current 5.36 does not run tests correctly on my Seagate 1 tb drives

 

[speeding_ant]

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.

[limetech]

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?

[Koperfild]

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:

 

[olympia]

 

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!

[limetech]

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.

[Ropo]

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?

[Rob_Esc]

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)

 

 

 

 

 

[Billped]

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