G Speed Q ESATA Write Speeds in Raid5

[Chris Murphy]

What model drives?

[Rainer Wirth]

Speed with esata varies, depending on how full your drives are. If your drives are filled up let’s say 30 % you should get around 180-200MB/s if the drives are filled up more than 70% speed is going down to less than 100 MB/s.

cheers

Rainer

factstory
Rainer Wirth
phone_0049-177-2156086
Mac pro 8core
Adobe,FCP,Avid
several raid systems

[Kevin Colber]

This thing is nearly empty and we are seeing 95MB/s write. Read is great at 250MB/s based off of the AJA and Blackmagic tests.

[Kevin Colber]

This thing is nearly empty and we are seeing 90MB/s write. Read is great at 250MB/s.

Drives are HGST 4TB 7200 SATA 6.

[Chris Murphy]

If it’s the HUS724040ALE640 then I think there is more than one thing going on that’s not right, because those drives should do ~180MB each, so striped reads should draw a lot more than 250MB/s depending on the specifics of the configuration. The write speed could either be low for the same reason the read is, which is an chunk size that’s not appropriate for the workload; or it could be excessive RWM due to misalignment, as these drives are 512e AF disks.

So more information is needed. Exact model number. What’s the raid card. What’s the chunk and/or stripe size. How many disks. What is the work load (how big are the files being copied when the 95/250 benchmark is determined.)

[Kevin Colber]

The drives are:

HUS724040ALE640, 4 disks.

I’ve done the write test at 2gb, 4gb, and 8gb.

Can you tell me how to check the other options?

[Kevin Colber]

Some more tests:

FW800:

2.0GB, 65MB/s Write, 81MB/s Read
8.0GB, 60MB/s Write, 82mb/s Read

ESATA:

128MB 59/234
512MB 98/245
1GB 98/249
2GB 99/238
4GB 97/250

For reference this is a G-Tech G Speed Q 16TB Raid 5

[Alex Gerulaitis]

[Kevin Colber] “Hey gang- can anyone give me any info on what their write speeds on a G-Speed Q in Raid5 are?”

Haven’t tested it myself. Similar 4-bay multi-interface RAID5 boxes from CineRAID and ProAvio – read speeds similar to yours; write speeds in the 150MB/s range.

G-Tech used to post benchmarks on their product pages – don’t see any for the “Q”. Bummer.

The only speed test I saw for the “Q” has numbers similar to yours (on 3G eSATA): 174/104. The review is from two years ago though, with a different Q model – the one that didn’t have USB 3.0 yet. (The funny part is that even their current datasheet still has USB 2.0 on it.)

It’s unlikely anyone here will be able help you no matter the alphabet soups they throw at the problem: the only way to get real answers is to ask fellow Q users, what numbers they are seeing, and you may have better chances on G-Tech forums.

My hunch is that what you’re seeing is normal, the effect of either a slow RAID5 brain, or having write caching off on the drives or on the controller. (The latter is the right way to do it with RAID5 controllers w/o battery backup.) I could be wrong of course. The Q however was never intended a speed demon despite the “speed” moniker: they’re primarily backup and archival devices.

[Chris Murphy]

For chunk size, the goal is to maximize full stripe writes. Full stripe is chunk size * number of data disks. To find chunk size you need to look for a chunk or stripe size value in your raid software. And you need to know something about your typical write sizes, to figure out chunk size. A too high chunk size gets hit with RWM penalty at the raid chunk level. Too small chunk size means the disks become excessively bound in IO which also hurts performance.

Another factor is the HFSJ/HFSX journal. It’s 8MB per 100GB of file system up to 512MB. So you have a 512MB journal which is quite large. It might be worth disabling the journal and redoing your tests to see if there’s any change. Ultimately you want the journal on to avoid either long fsck times in the event of a crash, or not doing fsck at all in which case it’s a matter of not much time before the file system trashes itself. It can be temporarily disabled through the diskutil command. If performance picsk up dramatically then you probably have moderate to heavy metadata writes, and to fix this longer term either reduce the chunk size, or relocate the journal to an SSD, which is supported but not in the GUI.

Another source of RWM performance hit is when the raid chunks aren’t aligned to a drive’s physical sectors. This ought to not happen these days. But it depends on if the disks are partitioned or not and what partitioned them and if it does so correctly. This is not the same thing as partitioning the resulting array that appears in Disk Utility. The raid manufacturer should be able to tell you this.

[Rainer Wirth]

Alex is right,

these are quite normal parameters for esata. For editing the read parameter is much more important than the write speed. If the array is filled up, the speed goes down significantly, that’s why we use esata for storage only.

cheers

Rainer

factstory
Rainer Wirth
phone_0049-177-2156086
Mac pro 8core
Adobe,FCP,Avid
several raid systems