-
G Speed Q ESATA Write Speeds in Raid5
-
The issue isn’t eSATA, which is the exact same thing as SATA except for the physical connector. Protocol and bandwidth are the same. Also eSATA neither correlates nor causes slow down when the array starts to fill up. Array slow down is a function of file system fragmentation, which also leads to heavier raid layer RWM penalties.
The bandwidth of the eSATA connection in this case is 600MB/s after accounting for 8b/10b encoding overhead. The drives can do large sequential writes at ~135MS/s per drive. The stripe width is 3 in this case, which makes for 405MB/s full stripe writes: assuming the raid hardware in these units can do that, and the layout is optimized for the workload, any of which may not be true. But the performance hit isn’t due to eSATA or the drives, and probably isn’t due to the Fasta card or the PCIe-TB enclosure or the bandwidth limits of Thunderbolt compared to a legit 4-lane PCIe slot.
I think it’s either misaligned chunks to 4K physical sectors of the drive causing drive firmware RWM, and/or the lack of full stripe writes causing excessive RWM of chunks at the raid layer. And the raid hardware isn’t powerful enough to optimize its way out of that given the workload.
I just looked at the user manual for this box and it doesn’t show a configuration utility option for setting chunk size or layout options. Rather than powering down the unit, pulling a drive, and putting it on a separate SATA bus, and looking at sector data to figure these things out, it’s easier to just ask G-Technology support what the chunk size is, and confirm/deny that their firmware supports proper alignment of chunks on 4K physical sector drives.
I’d also question the testing method that comes up with 95MB/s writes, which may not reflect the intended actual real world usage. If the workload between the test and the real world aren’t the same, the test is useless. It may indicate better or worse than real world performance.
-
so Chris,
if you are so fond of esata and it is terribly speedy, why do we end up with thousands of bucks spending in a FC array?
Our experience has showed us, that esata is not the speedyist solution on the market and not that reliable when it come sto speed and a 70% filled up array.
I think, the parameters showing with AJA are correct and underline our experiences.cheers
Rainer
factstory
Rainer Wirth
phone_0049-177-2156086
Mac pro 8core
Adobe,FCP,Avid
several raid systems -
I did not state a like or dislike of SATA or eSATA. I stated that its available bandwidth, in this thread’s context, is a non-factor. Given the read is 225MB/s which is below the SATA Rev 2.0 3Gbps bandwidth, it makes no sense to suggest FC alone would solve this problem. The bandwidth between array and host is not the bottleneck, it’s something else.
FC to SATA is apples to oranges. Totally different available bandwidths by year, different protocols SCSI vs ATA and hence different command queuing and ECC, and FC implies SAS drives so different mechanisms possibly faster rotational rates. It’s like, nothing is the same between them. But it wouldn’t matter if the G Speed Q had an FC port capable of 8GFC, the host to array bandwidth is not being saturated now as it is.
I think your experience is that you’ve used unreliable SATA cables, drives, cards, raids, and as for the 70% full business again that has nothing to do with the connector being used. The connector knows nothing about how full a hard drive is. A file system does, and the raid RWM processing will be affected by this as well.
-
But Chris,
how is it, that we experience huge speed loss with esata connections in comparison with let’s say SAS connections. In theory you could be right, but daily practise tells us another story. We’ve tested this under various conditions – it’s all the same – esata doesn’t provide us as a production house with enough speed we need for online editing. We therefore have decided that SAS and FC are the only solutions for us. In the future Thunderbolt might be an answer, but even thunderbolt doesn’t reach the speed of a 4x8GB/s FC Raid. In this thread someone is coping with the actual speed limits of esata, and we have to accept it.
cheers
Rainer
factstory
Rainer Wirth
phone_0049-177-2156086
Mac pro 8core
Adobe,FCP,Avid
several raid systems -
[Rainer Wirth] how is it, that we experience huge speed loss with esata connections in comparison with let’s say SAS connections.
If the comparison is SATA vs SAS, SNIA has more than one slideshow that explores the differences that result in better scalability for SAS that go beyond bandwidth. The difference between SAS 3Gbps and 6Gbps, and SATA 3Gbps and 6Gbps isn’t just one of bandwidth. There are other meaningful changes to the protocols including command queueing that for certain use cases can make a huge difference. So even when bandwidth saturation isn’t the bottleneck, there can be differences simply because of the different command set being used. So while you have not stated exactly what products you were comparing, I’ll argue it will be difficult to answer your question because there are a lot of differences possible between SATA and SAS.
But by continuing to ding eSATA specifically, you’re implying a meaningful difference between eSATA and SATA which is untrue.
We therefore have decided that SAS and FC are the only solutions for us.
Lots of people have arrived at this conclusion as well, which is why it’s good to have SAS as an alternative to SATA. But you keep saying eSATA as if it’s different from SATA is sortof annoying.
In the future Thunderbolt might be an answer, but even thunderbolt doesn’t reach the speed of a 4x8GB/s FC Raid.
And the specs bear this out. You don’t need to test it. But I think you mean 8Gbps or 8GFC rather than 8GB/s. 8GFC is ~1.6GB/s.
In this thread someone is coping with the actual speed limits of esata, and we have to accept it.
No they are not. The bandwidth of the connection is not being saturated even accounting for 8b/10b overhead, on reads let alone writes. The problem is elsewhere.
-
FWIW:
I added an ATTO H680 SAS Card with an ESATA Fan Out to my echo express box, which boosted my write speeds into the 195MB/s+ range- someone above mentioned the CalDigit cards and G-Speed Q’s didnt like each other- they were right.
-
[Kevin Colber] “I added an ATTO H680 SAS Card with an ESATA Fan Out to my echo express box, which boosted my write speeds into the 195MB/s+ range- someone above mentioned the CalDigit cards and G-Speed Q’s didnt like each other- they were right.”
For a 4-bay eSATA RAID5, that’s an awesome speed. Would you have a screenshot by any chance?
-
What happened to read speeds? 195MB/s writes are still not saturating the SATA 3Gbps link. If the reads are relatively unchanged, then I’d say you don’t have an mis-alignment, nor is there excessive RWM.
-
This has been my experience too.
G-Speed Q and G-Speed eS drives are picky about the eSATA card you connect with. I’ve also experienced the same speed bump with the Atto H680 and SAS-4x eSATA cable. But that card-cable combo doesn’t work with G-Tech RAIDs if they are ‘RAIDed’ using the G-Tech SATA card.
It’s also very interesting to read all the other comments about your write speed issue.
———————————–
Neil Sadwelkar
neilsadwelkar.blogspot.com
twitter: fcpguru
FCP Editor, Edit systems consultant
Mumbai India -
[Neil Sadwelkar] ” I’ve also experienced the same speed bump with the Atto H680 and SAS-4x eSATA cable.”
Very curious about that. Would love to test the Q with a “known good” eSATA card that has been proven to run at 250MB/s (in 3G). Just can’t fathom needing a $300 SAS HBA to run the Q at full speeds.
Reply to this Discussion! Login or Sign Up