I am currently running 4.5 Beta.

Both Unraid and gaming PC on the same Netgear 108 Switch (gigE).

Parity Drive on separate PCI Controller

2 drives on internal SATA II.

Dual Core 7300, 4GB Kingston ddr2 ram, Asus P5e WS MB: Southbridge with 6 onboard SATA,  2 External, 1 PCI-x, 2 pcie-16x, 2 pci,  2 x Marvell88E8056 Dual Gb LAN

 

Write speeds using terracopy fluctuate between 4MB/s and 22MB/s, back and forth.

I am wondering what is causing the slowdown. I am assuming it is the writing part that slows it down, but should one SATA II 1TB Seagate drive, with no other drives or data being transferred, be able to write at 22MB/s non stop?

 

What software do people use here to test write and read speeds with real wold data (1GB, 4GB, 8GB Files/Movies)? What settings to test?

How do you setup network teaming ( assuming I can find a cheap switch that supports it. I do not think the Netgear one does.)?

I can post the syslog file later if needed.

Writing to unRAID results in 2 reads from 2 disks, and then 2 writes to 2 disks.  That happens with EVERY write.

 

If you want to measure throughput properly, do it with a 1GB file and a stopwatch.

 

And if you want to improve write speed, take your parity drive off the PCI controller, and put it on a port on the mobo.

This question comes up often, has been discussed often, really should be in the FAQ.  BubbaQ has, in his usual succinct way, explained it.  I'm not sure what the best way to search it is, but there is much more thorough discussion elsewhere in the forums.

 

I would recommend also reading the Improving unRAID Performance wiki page.

Thank you gentlemen, I have read the faq and perf forums. I guess I am just trying to understand in detail why it fluctuates to such an extent, and weather or not that is normal, as this is a new server build for me.

Yes, fluctuations on write are normal and, in fact, are not specific to unRAID RAID-technology. It's related to buffering. unRAID provides a way to side-step the issue, by adding a cache disk to your server. This both smooths out the transfer and increases throughput (quite a bit). The down side is that the transferred material is not parity protected straight away.

Thank you gentlemen, I have read the faq and perf forums. I guess I am just trying to understand in detail why it fluctuates to such an extent, and weather or not that is normal, as this is a new server build for me.

 

Depending on how much ram you have,  the server receives as much data as possible and puts it into the buffer cache.

The buffer cache will hit a point whereby it is getting full, or a kernel tuning is reached.

Thereafter the kernel starts writing data in the buffer cache

As explained previously,

Each write requires 1. read of old data,  2. read of old parity,  XOR old data out of parity, XOR New data block with parity, 3 write of data, 4 write of new parity

These four operations slow down the write.

 

This is why you will see a temporary burst at high speed, then a slow down to sometimes 4MB/s, then it will toglle back up,, then back down again.

 

It's not normal for it to be quite this bursty (from my experience). The bottle neck is the shared parity drive plus the fact the data is not striped.

 

A cache drive would help even this out if write speed is a priority.

 

I have 8GB and I still get the high burst, slow writes...

I generally throttle my network transfers with rsync at around 8-12MB/s and I do not see the burst issues unless there is more then one transfer.

Thank you for the good info.

I figured out what was killing me perf wise. I had a bad drive, that finally became unspinable. It was causing at 1.5GB/s cap on that sata controller as a result.

I will redo test now that the problem is gone...It was my parity drive to boot.