copying large 10gb files to unraid. network utilization seems go to back and forth between 0 percent and 30 percent. What's causing that? is the unraid box having trouble keeping up with calculating parity as I'm writing?

 

 

copying large 10gb files to unraid. network utilization seems go to back and forth between 0 percent and 30 percent. What's causing that? is the unraid box having trouble keeping up with calculating parity as I'm writing?

Calculating parity is nearly instant.  Reading and writing the disks takes time.  See the explanation in this thread:

http://lime-technology.com/forum/index.php?topic=4390.msg40684#msg40684

so that's somewhat normal? My parity disk is a fast sata drive and the data being written in that example is an IDE drive. when transfers are low I'm waiting for things to sync up and such?

 

Here's another... this seems kind of crazy. I'm going to add a cache disk and see what happens....

Yup... perfectly normal when writing to an array drive.

Interesting that the fluctuations appear to be a result of the gige being able to fill buffers on the server and then the pause while the buffers clear. On my 100Mbps network I can get a flat line at almost 100% during a large file transfer.

 

Peter

Without monitoring what is happening on the client it is impossible to see why the copy is stalling. Usually that last trace indicates another process is accessing the hard disk or interupting the copy whilst doing something else. My best guess would be a download or some sort (torrent s/w running on the client) or windows update, Windows firewall/ICS or a WMI process is interupting the copy.

 

The initial trace is much more of a "normal windows network trace".   

Here's another... this seems kind of crazy.

@Aaron J Anderson:  Do you want to do a little experiment?

Telnet to your server and apply the two tweaks described here.

Then redo your test and post the new picture here.

I am curious to see what the new picture will look like.

 

---

(BTW, what are the specs of your unraid build?)

 

 

As a result of my experiments I ended up modifying the following line in my syslinux.cfg:

  append  elevator=cfq  initrd=bzroot

And also I added the following line to my GO script:

  for i in /dev/[hs]d? ; do echo 128 > /sys/block/${i:5}/queue/max_sectors_kb ; done 2>null

 

 

Are those the tweaks you speaks of?

 

 

I'm on a bunch of 500gb drives.

2gb of ram. xeon 3.2 and intel GB networking.

Are those the tweaks you speaks of?

 

Well, yes, but modifying the syslinux.cfg and the go script would require a reboot of your server.

You can just as easily test this without rebooting. Just telnet into the server and type:

for i in /sys/block/[hs]d?; do echo deadline > $i/queue/scheduler ; done
for i in /sys/block/[hs]d?; do echo 128 > $i/queue/max_sectors_kb ; done 2>null

Then, if there is any improvement, then you can go ahead and modify the syslinux.cfg and the go script.

 

Depending on the specs of your unraid box, you may or may not see a big improvement.

I am still curious to see your new picture.

 

Purko

 

 

Updated to beta8 and here's my performance:

 

That's such a pretty graph compared to the last ones. Nice speed boost too.

 

Peter

Updated to beta8 and here's my performance:

 

Here's your performance of what?

READS or WRITES?

 

I bet the picture you posted was taken when you were READING from your unraid server.

 

No. That is my WRITE performance.

Amazing!

 

You sure?

I mean, that's a write to a disk in the parity protected array?

 

Haha. Yes. I'm very very sure.

Don't see any MB/s or Mbps? Could you please post more and also what kind of array and system you have. Thanks much!

That's using 30 percent of a gigabit network connection, so 300mbps

 

The system is a p4 3.2 xeon desktop board from 2004 with 4x500gb IDE, one 500gb sata disk on board, and an 80gb sata cache drive that was not used for these tests.