I was running 4.0 for a long time and recently upgraded to the 4.3beta6.  So far, so good.  Since I was on a new release, I decided to rerun some performance metrics.  Transferring an ISO from unraid (directly from the disk, not a share) to my windows box and the other way around.  I am not a fan of synthetic tests - real-world all the way.

 

~4GB file.  Read speed is 24.5MB/sec, write is 12.0MB/sec.  Both are with the "30% tweak" discussed elsewhere (helped reads by 24%, as expected, not writes).

 

I have the Asus P5B-E running SATAII drives (WD and Seagates) through a Dlink GigE switch and using Cat5E - 1GB of RAM and running a low-end dual core.  Running directly from the unraid to my desktop yielded similar speeds in the past.  My GigE on the PC is a Netgear 311 and I was using the onboard GigE on the Unraid.  Parity is one of the WD 5400 drives, but when I had 4.0 and using one of  my 7200 Seagates writes were similar.

 

Tonight I installed an Intel Pro/1000 (PCI) on the unraid and was hopeful of much better performance - didn't happen.  Reads and writes improved by 5-6%.  I have a TX4 on the way so I can install another four drives and will try some metrics on that vs. the onboard SATA controller.

 

Any comments?  I hear about some folks getting double my read performance and much better writes as well.  Should I try the onboard GigE on the Asus and move the Intel to the PC instead?

 

One interesting observation: when watching the network activity on my PC while transferring files, if I do anything on the PC (i.e. open a file, calc a spreadsheet), my performance goes to near zero.  The test results above are all "hands off the keyboard", but is this symptomatic of a problem on the PC's end rather than with the Unraid?

 

Syslog attached.

 

 

Bill

My initial impression is that part of your problem is not in Linux, but in Windows.  Try a copy from one Windows box to another.  Also, what version of Windows are you using?

 

Also, what is the internal (copy from /mnt/disk1 to /mnt/disk2) copy throughput on both unRAID and on your Windows box? (if you have 2 disks on the Windows box... if not, put one in temporarily).

 

Also try isolating the systems from other network traffic by hooking them directly to each other w/o a switch.

 

Finally, remember Samba is a reverse-engineered hack.  Try a copy between Windows and a Linux box via NFS.

 

It was only recently that MS agreed to let the Samba team see the internal documentation of SMB so they can actually rewrite Samba as a real application rather than a hack.  Look forward to that improving Samba.

 

In any event, doing all this you will find some set of conditions that will give you the best throughput.  Use that as you baseline, and start changing back to your original setup, one change at a time.

Bill, your syslog looks OK, but were you aware that it is a 4.0 syslog from Feb 8?

 

My numbers look very similar to yours, almost 30MB/s for reads and just under 10MB/s for writes, also all SATA II.

RobJ - Doh!  I attached the wrong one.  Thanks.  New one attached.

 

bubbaQ - WinXP/SP2.  I will try some internal-to-XP and internal-to-Unraid times.  I previously had unraid and my windows box in a direct connection w/little difference.

 

 

Bill

Interesting results.  I took bubbaQ's suggestions to heart and isolated the network such that I could find out both systems' internal maximum speeds.  None of the below travel over my GigE network.

 

First, the PC: the best write I could get out of my IDE-based box is 28MB/sec - that is copying from one internal drive to the other.  Both drives are a couple of years old (160GB).  Making the grand assumption that one drive's read speed is higher than the other's write, that means that even if I am hooked up the the fastest hardware RAID box I could build, my reads TO DISK will be capped at under 30MB/sec.  To memory (as with smaller files or when playing music/movies) would likely be faster, but I can't yet tell by how much.

 

Second, the Unraid: doing a cp from one drive to another (both Seagate SATAII 300GB/16MB with a WD Green 1TB parity) got me 13.9MB/sec.  That should be close to the maximum write I would ever get (PCI bus traffic from the internal read could mean real-world writes could be better).  I was curious to find out the maximum read, so I cp'd the same file from the same drive to /dev/null and got 58.9MB/sec.  That should be the maximum read I would ever get.

 

My next step is to simultaneously download two files over the GigE to two different PCs to see if together I can get above 30MB/sec.  Since the maximum read is ~double that of the reads I am seeing to my PC, there is no need to stack a third download as two should saturate the unraid though it would be interesting to see if more simultaneous loads would actually decrease performance.  Unfortunately, I only have one GigE-capable PC in the house.  Bummer.

 

One thing to keep in mind is that I am trying to calculate how many simultaneous loads I could reasonably expect to get and was using the "max to one machine divided by HD stream requirements = answer" logic.  That logic was flawed going in (i.e. capable of handling one X stream doesn't mean capable of handling five concurrent 20% streams) - I knew that, but what I didn't realize was that my one-stream-max-measurement-box was itself a limiting factor.

 

 

Cheers,

Bill

 

 

 

First, the PC: the best write I could get out of my IDE-based box is 28MB/sec - that is copying from one internal drive to the other.  Both drives are a couple of years old (160GB).  Making the grand assumption that one drive's read speed is higher than the other's write, that means that even if I am hooked up the the fastest hardware RAID box I could build, my reads TO DISK will be capped at under 30MB/sec.  To memory (as with smaller files or when playing music/movies) would likely be faster, but I can't yet tell by how much.

 

I was wondering if this test was with both drives on the same IDE channel or on different IDE channels.  I remember reading that the entire channel was either in read or in write mode and that copying from one drive to another is faster if on separate channels.

You can also used the NUL device in Windows/DOS for an internal transfer test juls like /dev/nul in *inux.

 

open DOS window and:

 

copy x:\abc.iso NUL

bjp999. I'm pretty sure they are on separate channels.  The "location" in hardware profiles shows one as "0(0)" and other other as "1(1)".  Update: I popped the hood and checked, definitely on separate channels.

 

bubbaQ, I wasn't aware of that - the NUL-based PC read test showed 39.0MB/sec - this is the fastest I can read off of one of my IDE drives.

 

What I seemed to have proven is ... nothing.  I still don't have a valid "what is the fastest I can read off of my unraid?" metric as my current metric is constrained by the write speed of my PC and (potentially, but not proven) a constraint of my switch.  The next thing to try is what I described earlier - stacking multiple read streams from the unraid to two separate PCs.  If this gets me near the 59MB/sec internal ceiling of my unraid, then I can eliminate the switch/network as a problem.

 

Moving forward, I am building a new PC since I am doing an awful lot of music/video processing.  My current uni-core+IDE is not serving this function very well.  I will repeat the experiments once that is complete.

 

 

Bill

Remember, in a CSMA/CD switched fabric like Gbit Ethernet, you will max out at about 30% of wire speed.  So if all the PCs and hard drives can do over 50MB/s, you will be limited to much less than that by the wire.