This is writing using a cache drive. I did transfer more files about ~1TB and the speed was steady 75 MB/s to 80 MB/s

 

Those are some nice numbers!

 

Do you attribute the significantly faster speeds to using a cache drive as opposed to writing to array, or is this because of the jumbo frames tweak?

 

Any chance you can run the same test without the jumbo frame tweak to see if it makes a difference?

 

Thanks!

 

 

DB

 

[EDIT] Also, where exactly did you put the tweak? The Go script?

Hi Guys,

 

I would like to mention that after ussing a WD EARS green cache drive and performing the following jumbo frames twick, I now get ~90MB/s to 100MB/s transfer speeds. 

 

ifconfig eth0 mtu 6000

 

That is a huge improvement.

 

 

 

Did you also set the mtu on your PC?

 

No, I didn't. Only on the unRAId server.

 

 

 

It is really odd that this does anything for several reasons. The IP standard requires that all hosts on a subnet have a common MTU. But that is not the real issue. Data transfer is from your PC which should default to 1500 bytes. The server is sending small acknowledgement packets which should be 576 bytes in size. The PC is still sending the data in 1500 byte packets. The server is sending acknowledgements of 576 bytes. So the 6000 byte MTU is never being used.

The biggest factor I have seen is switch quality.

 

I have never seen > 60 MB on consumer hardware on a gigabit network.

 

I replaced my switches with a hp switch and always see 90-100MB speeds to a pc and a linux server.

 

My unraid server is VMed so I see speeds much less (12-25MB) write.  I am waiting for /dev/vdx support.

I was under the impression that 25MB/s was OK too?

 

Interesting I read this thread, I've noticed that I use to average 16~23MB/s, and sometimes above this write speed, but it's dropped to 10~12MB/s recently, so I need to do some testing as to why it has dropped from me .

 

As you know, unRAID isn't built for speed, but rather more for redundancy. In a situation where the unRAID array is always protected (not using a cache drive) and you're using good hardware (mobo/disks/LAN devices), the I/O internally and externally to and from the server should be acceptable for home use. Most unRAID users use their servers for media streaming or as a personal backup solution. Reading from an unRAID box should result in 90~100 MB/s at best, I presume.

Wanting anything about 25MB/s write speeds using a fully protected setup, you could forgo unRAID for another NAS solution (FreeNAS/OpenSolaris server and use a ZFS array), or buy a 3rd party product. Remember though, you'll be trading off speed VS redundancy, which no other RAID solution offer like unRAID does.

Using a cache drive in your server is good for a speed boost, but what if the cache drive fails not long after you've written several gig's worth of data to it, without having the chance to write the cached data to disk and parity? You need to question where you can sacrifice this risk for speed, and whether you can recover from this possible situation? Fair enough if this isn't such an issue for you in the instance that you loose your cache drive and you can recover this data, but if you have the tendancy to move your data from source to destination, that singe move of data getting lost on a faulty cache drive could be a problem one day.

Another way to vastly improve write speeds, if you needed to transfer several hundred of gig's worth of data or anything greater then a TB, you can directly attached your source drive (Being an external HDD using USB2/eSATA or even a SATA or other hard drive) to your server, mount the disk and use a cp commed to move your data internally, bypassing the LAN and client altogether. Even in a standard unRAID setup with no cache drive, you'll be achieving far greater writes speeds in a DAS fashion, rather than a disk to LAN to disk bottleneck.

 

Just a few things to take in. I'm an unRAID fan and use it for redundancy, not for speed.

 

Cheers

I don't delete my original copy for at least 24 hours. This way I'm sure the data has been moved into the array and I can still survive a single drive failure. The machines I'm building for other people don't have a cache drive.

I don't hink is the cache drive. When I did the jumbo frame setting immediatly the transfer speed jumped to 75 to 80 MB/s.

Without the MTU setting the speed was about 55 to 60 MB/s

 

Yesterday I removed the parity drive and cache drive, and transfer about 1 TB of data. The speed is steady 75 to 80 MB/s

 

The MTU seting is set in the /boot/config/network.cfg file. You have to add at the end of the config file the parameter MTU=6000

 

 

This is writing using a cache drive. I did transfer more files about ~1TB and the speed was steady 75 MB/s to 80 MB/s

 

Those are some nice numbers!

 

Do you attribute the significantly faster speeds to using a cache drive as opposed to writing to array, or is this because of the jumbo frames tweak?

 

Any chance you can run the same test without the jumbo frame tweak to see if it makes a difference?

 

Thanks!

 

 

DB

 

[EDIT] Also, where exactly did you put the tweak? The Go script?

Sorry if this has been answered elsewhere in this thread and I have missed it, but are you saying with this tweak you get 75-80MB/s when writing directly (i.e. not using a cache drive) to the array WITH parity protection in place?

 

If not, can you test this, as this is surely the acid test of an improvement in write speeds to an unRaid array?

 

Without the MTU change the transfer is about 55 to 60 MB /s, with the MTU setting I transfer yesterday about 1 TB with 75 to 80 MB/s steady speed.

 

 

 

Hi Guys,

 

I would like to mention that after ussing a WD EARS green cache drive and performing the following jumbo frames twick, I now get ~90MB/s to 100MB/s transfer speeds. 

 

ifconfig eth0 mtu 6000

 

That is a huge improvement.

 

 

 

Did you also set the mtu on your PC?

 

No, I didn't. Only on the unRAId server.

 

 

 

It is really odd that this does anything for several reasons. The IP standard requires that all hosts on a subnet have a common MTU. But that is not the real issue. Data transfer is from your PC which should default to 1500 bytes. The server is sending small acknowledgement packets which should be 576 bytes in size. The PC is still sending the data in 1500 byte packets. The server is sending acknowledgements of 576 bytes. So the 6000 byte MTU is never being used.

 

 

Without the MTU change the transfer is about 55 to 60 MB /s, with the MTU setting I transfer yesterday about 1 TB with 75 to 80 MB/s steady speed.

 

 

 

Hi Guys,

 

I would like to mention that after ussing a WD EARS green cache drive and performing the following jumbo frames twick, I now get ~90MB/s to 100MB/s transfer speeds. 

 

ifconfig eth0 mtu 6000

 

That is a huge improvement.

 

 

 

Did you also set the mtu on your PC?

 

No, I didn't. Only on the unRAId server.

 

 

 

It is really odd that this does anything for several reasons. The IP standard requires that all hosts on a subnet have a common MTU. But that is not the real issue. Data transfer is from your PC which should default to 1500 bytes. The server is sending small acknowledgement packets which should be 576 bytes in size. The PC is still sending the data in 1500 byte packets. The server is sending acknowledgements of 576 bytes. So the 6000 byte MTU is never being used.

 

 

To an unRaid array with parity protectionin place but NOT using a cache drive?

Sorry if this has been answered elsewhere in this thread and I have missed it, but are you saying with this tweak you get 75-80MB/s when writing directly (i.e. not using a cache drive) to the array WITH parity protection in place?

 

If not, can you test this, as this is surely the acid test of an improvement in write speeds to an unRaid array?

 

This is with NO parity protection in place. I will have to perform some transfers with parity to see the difference.

 

 

Without the MTU change the transfer is about 55 to 60 MB /s, with the MTU setting I transfer yesterday about 1 TB with 75 to 80 MB/s steady speed.

 

 

 

Hi Guys,

 

I would like to mention that after ussing a WD EARS green cache drive and performing the following jumbo frames twick, I now get ~90MB/s to 100MB/s transfer speeds. 

 

ifconfig eth0 mtu 6000

 

That is a huge improvement.

 

 

 

Did you also set the mtu on your PC?

 

No, I didn't. Only on the unRAId server.

 

 

 

It is really odd that this does anything for several reasons. The IP standard requires that all hosts on a subnet have a common MTU. But that is not the real issue. Data transfer is from your PC which should default to 1500 bytes. The server is sending small acknowledgement packets which should be 576 bytes in size. The PC is still sending the data in 1500 byte packets. The server is sending acknowledgements of 576 bytes. So the 6000 byte MTU is never being used.

 

 

To an unRaid array with parity protectionin place but NOT using a cache drive?

With NO parity in place.

 

I can confirm these numbers as well.

 

On my recently built unRaid server, without both cache drive and parity, and with mtu set at 6000, i was getting 60-80MB/s write speeds. WITH parity, I am getting 30-40Mb/s write speeds. These are writes to a Hitachi 7k2000 drive. All my PCs and devices have MTU set to at least 6000. And I am going through a Dlink 1024D switch which is arguably not a consumer grade switch.

I can confirm these numbers as well.

 

On my recently built unRaid server, without both cache drive and parity, and with mtu set at 6000, i was getting 60-80MB/s write speeds. WITH parity, I am getting 30-40Mb/s write speeds. These are writes to a Hitachi 7k2000 drive. All my PCs and devices have MTU set to at least 6000. And I am going through a Dlink 1024D switch which is arguably not a consumer grade switch.

 

In my case I'm using a NetGear Gigabit 5 port switch and Dlink DIR 655 Gigabit router. The drives on my unRAId server are all Green.

 

I would be interested to know what the 'iperf' utility tells you (especially dianasta) about your network bandwidth. See here

 

iperf tells me that I'm achieving in excess of 110MB/s on my network, yet my writes to cache drive rarely go above 50MB/s.  I attribute this to an older, slow, drive being used as cache - I should try using a modern drive and see whether write speeds improve.

 

Having said that, my read speeds (from modern green drives) are very similar to my write speeds.

 

 

The biggest factor I have seen is switch quality.

 

I have never seen > 60 MB on consumer hardware on a gigabit network.

 

I replaced my switches with a hp switch and always see 90-100MB speeds to a pc and a linux server.

 

My unraid server is VMed so I see speeds much less (12-25MB) write.  I am waiting for /dev/vdx support.

 

I have two switches in the path, both very much consumer grade - a Netgear GS608 and a D-Link DGS 1008D.  Eliminating one of the switches does appear to give a marginal improvement in write speeds - around 5% faster.

 

I wonder whether setting a high mtu just on the unRAID end is, somehow, simply improving the network adapter to SATA adapter bandwidth (perhaps by increasing the size of a buffer somewhere)?

 

I will try experimenting with mtu later.

in my experience, not with unRaid, mtu changes are only effective IF all ends of the network support the higher mtu, and all switches/routers support it too. I had an older switch that didn't work well with non std mtus higher than 1500.

 

Also, setting the mtu to the max of 9000 didn't work well either because a few devices maxed out at 6000 and even though the network handshaking is suppose to still have this work, it actually decreased throughput... setting everything to 6000 seemed to be the best...