Hi, I hope this is the right Forum section for questions like this.

 

I just build my first unRAID (Intel G530 on a ASRock B75M with 4GB RAM) and for testing purposes I installed 2 HDDs (Seagate ST2000DM001). Formatted the drives, set a share and made a network share on my Win 7 PC. Now I copied some stuff over and... 30MB/s max. transfer speed over GBit LAN. Uh not nice, internally installed on my Win 7 PC these would write with ~80-100MB/s.

Did I overlook/forgot something in terms of configuration or where my expectations of GBit LAN just to high?

Is one of the drives parity and the other data?

If you have a parity drive, the slow down is due to computing parity on the fly - this is normal. This is also why UNRAID supports a Cache drive in which new data is written to it at full speed. Later, the slower copy to the protected array at the slower rate.

 

Note that if you update a file that exists in the protected array, the operation will happen on the protected array and not on the cache drive.

Check your Connection speed on the box, are you really connected at 1Gb/s or 100Mb/s?  I had mine negotiate at 100 one time, the only fix that worked was a reboot.  Forcing it to 1Gb command line wasn't working.

 

 

@deadsoulz: If he had only 100Mbit the transferspeed would only be around 10MB/s, he says he has 30MB/s, so everything okay with the connection.

 

30MB/s is a good value for a parity protected array, like the others already said, if you need more speed you have to use a cache drive.

30MB/s is very good speed for protected array.

 

It will only get slower when you start filling up the drives... 

Thanks for the answers guys.

Just to be sure, I checked the transfer speed without the Parity Drive - 60-80MB/s+.

 

But I'm still wondering why exactly is it so slow? The CPU doesn't seem to have a problem with the parity calculations (only ~60% CPU utilization) and the HDDs normaly have a Read / Write speed of 100MBs / ~ 60MBs.

You maximum possible theoretical write throughput to a protected drive in the array is:

 

  1 / (1/read-speed + 1/write-speed)

 

Or a reasonable approximation is also:

 

  (drive read rate + drive write rate) / 4

 

Your actual throughput will be lower.... but this will tell you how close you are to the theoretical maximum.

 

See this thread:  http://lime-technology.com/forum/index.php?topic=19083.0

 

 

Hi, I hope this is the right Forum section for questions like this.

 

I just build my first unRAID (Intel G530 on a ASRock B75M with 4GB RAM) and for testing purposes I installed 2 HDDs (Seagate ST2000DM001). Formatted the drives, set a share and made a network share on my Win 7 PC. Now I copied some stuff over and... 30MB/s max. transfer speed over GBit LAN. Uh not nice, internally installed on my Win 7 PC these would write with ~80-100MB/s.

Did I overlook/forgot something in terms of configuration or where my expectations of GBit LAN just to high?

 

You are lucky to get 30MB/sec. Unraid isn't designed or meant for speed. It even says that in the online wiki. Trust me, no matter what you do to try and make it go faster it will not work. I've tried.

 

Trust me, no matter what you do to try and make it go faster it will not work. I've tried.

 

Not true.  http://lime-technology.com/forum/index.php?topic=19507.msg175723#msg175723

 

Wondering, would an SSD cache drive make any sense at all? I've been moving a ton of data as I collapse servers and have been hitting the write speed limits. A cache drive would probably fill up moving this much though, could the mover be scheduled to run much more frequently maybe? 60-90gig SSD have come done in price :-)

No, just get a good spinner, since the max you can pump through 1gbE is about 105MB/sec.

Wondering, would an SSD cache drive make any sense at all? I've been moving a ton of data as I collapse servers and have been hitting the write speed limits. A cache drive would probably fill up moving this much though, could the mover be scheduled to run much more frequently maybe? 60-90gig SSD have come done in price :-)

 

Problem is that unRaid is not designed (till now) for the use of SSD's. It dosn't support files systems like ext4 or the trim command.

I think there was a discussion adding this in unRaid 5.1, but we dont even have a 5.0 final till now.

 

I mean SSD have some pros like the low amount of power they need, but the reliability of the cheap consumer SSD suck

I had three damaged SSD's in the last 12 months, more than i had damaged Harddisk in the past 15 years.

 

By the way i use an old 250GB 2,5" HDD from my Macbook Pro as Cache, which at least boosts my transfer speed up to 50-60MB/s.

But I'm still wondering why exactly is it so slow? The CPU doesn't seem to have a problem with the parity calculations (only ~60% CPU utilization) and the HDDs normaly have a Read / Write speed of 100MBs / ~ 60MBs.

 

bubbaQ expressed it mathematically, but here's the longer version....

 

Because, when you write new data to an array drive, even under optimal conditions unRAID must first read the array drive, read the parity drive, do the parity calculation based on the old data, the old parity, the new data  (that's actually the quick bit), wait for the drives to finish their rotation, then write the new data to the data drive, write new parity to the parity drive.  That's four disc access to two drives which must both rotate at least one complete revolution.