How to market SATA

[LiamC]

And here's a smack down:

http://www.aceshardware.com/forum?read=105052634

someone posted a link about a "review" of RAIDCore's RAID controller, and the above is a response - thought it funny enough to share.

PS, anyone notice how quiet the forum has been without Tony

 

[blakerwry]

I dont believe what he said was true, he generalized it so much like it was a flaw in the S-ATA interface that some controllers don't support both write-through and write-back caching.

He also makes it seem like S-ATA is the problem when using a host based RAID controller... the truth is that host based RAID controllers exist in ATA, S-ATA, and the SCSI market. Hardware controllers exist in all these markets as well.


I do find it his facetiousness a little funny, but not more than a chuckle.

 

[Howell]

I dont believe what he said was true, he generalized it so much like it was a flaw in the S-ATA interface that some controllers don't support both write-through and write-back caching.

He had two points. One ATA specific and one that card specific.

 

[blakerwry]

maybe I missed it, but what was his S-ATA gripe? the only gripes I saw were completely unrelated to interface,

 

[CougTek]

If SATA RAID controllers were all like the Promise and HighPoint models, this rant would be deserved. But a 3Ware Escalade compared favorably to any similarly priced or slightly more expensive SCSI RAID controller.

I would dare to put 8 Western Digital Raptor WD740D hooked to an Escalade 8500 for a server in a corporate environment. I would probably use RAID 10 instead of RAID 5 though. Unless I have huge space requirements. Just easier to deal with a passed out drive in RAID 10 than in RAID 5. And it would still probably be cheaper than a RAID 5 array of SCSI drives.

 

[CougTek]

I withdraw my comment about RAID 10 with SATA drives would be cheaper than RAID 5 with SCSI. I thought the Raptor WD740GD was cheaper than its SCSI relatives, but a visit on Pricewatch told me that 73GB 10K U320 SCSI drives cost about 300$-325$ for the latest generation, just like Western Digital's latest offspring. So it basicly comes down to the cost of the controller and then against, the 3Ware Escalade 8506-8 isn't mcuh cheaper than, let's say, a LSI MegaRAID 320-2 (500$ versus 615$).

So in the end, the main advantage of the SATA solution is the improved airflow inside the enclosure because the cables are much thinner. But that's not a great advantage since you'll only need two SCSI cables for an 8 drives setup comparatively to 8 (much thinner) SATA cables for something similar on the SATA side.

Hmmm...lower noise maybe? Might be an advantage if the server isn't in a remote place. Next time I win a million dollar at the loto, I'll buy both setups and tell you wich one is better.

 

[blakerwry]

are you forgetting that many SCSI controllers use a single or possible dual channels.. where as S-ATA has as many channels as drives. This would allow for a better maximum transfer rate on highly sequential accesses. (upto the maximum of the card and the PCI bus it's attached to).

 

[CougTek]

With Ultra320 scuzzy now relatively mainstream for scuzzy RAID controllers, I don't see that as a particular disavantage, at least not until a few more drives generations.

 

[blakerwry]

8 drives times 60MB/sec per drive is 480MB/sec... don't forget that even on a SCSI channel only one device can transmit data at a time... I see this as something that people doing sequential transfers across large arrays should worry about.

If I had 8 drives I would certainly want a dual channel controller over a single channel (even if the dual was a u160 vs a single u320).

 

[CougTek]

don't forget that even on a SCSI channel only one device can transmit data at a time...

what?

 

[blakerwry]

Only one drive can send data at a time... if you have 8 drives on a cable they are sharing the bandwidth of that channel. This is in contrast to S-ATA where each device has its own dedicated connection.

This is very similar to the differences between a hubbed(shared) network and a switched network.

 

[CougTek]

Yes but each scuzzy drive transmit its data by packets at the speed of the interface. When mulitple drives have to transmit data simultaneously, each drive transmits no more than what's in its buffer and then the arbiter switches to another drive. Overall, contrarily to ATA, a scuzzy bus isn't limited by the speed of it's fastest drive*, but by the overall bandwidth of the bus.

Sure, there's a little overhead eating some bandwidth when the arbiter is busy to allow each drive to receive/transmit data on the bus, but that's probably no more than ~10% of the bandwidth (I have no numbers for the overhead).

I agree that eight single SATA channels provide a greater total possible bandwidth compared to a single or a dual U320 SCSI bus. But think about the amount of bandwidth a single U320 channel has and well, chances are very good that it won't be the bottleneck in your system.

That's why I don't really see bandwidth as a real advantage/disavantage in this case.

* Assuming all drives are U320 scuzzy compliant

 

[CougTek]

This is very similar to the differences between a hubbed(shared) network and a switched network.

I haven't seen numbers, but I would almost be ready to bet money that an U320 SCSI channel is way, WAY more efficient than an ethernet hub for packet arbitration.

 

[blakerwry]

From the numbers I've seen a u320 channel isn't even 90% efficient with just 4 drives... with 8 I bet it'd be less efficient.

 

[LiamC]

Now isn't this something that we should benchmark - to find out the truth? Would make a great article - all we ned is for someone to fork out for 8 NG raptors + hi-end SATA controller as well as some USCSI luvin' :eekers:

 

[CougTek]

BTW, the 615$ scuzzy RAID controller I mentioned above was a dual U320 channel LSI MegaRAID 320-2. So it would be 4 drives per channel for an 8 drives RAID array.

I would really like to see objective benchmarks comparing a LSI MegaRAID 320-2 versus a 3Ware Escalade 8506-8.

 

[CougTek]

It would only cost ~2900$ for the SATA RAID array and ~3200$ for the scuzzy one.

Hey, Christmas' coming.

 

[blakerwry]

i dont think I've been that good this year coug.

 

[mubs]

Fushigi's running 65 raided drives in 8 sets on one host; he said that in response to a post I'd made, but I can't seem to find that post right now to reference it. He's got practical knowledge of this situation; maybe he can shed some light on this.

 

[Fushigi]

Fushigi's running 65 raided drives in 8 sets on one host; he said that in response to a post I'd made, but I can't seem to find that post right now to reference it. He's got practical knowledge of this situation; maybe he can shed some light on this.

But it's nowhere near Wintel land. PowerPC-type CPUs and OS/400. The disk subsystem is U160, no more than 5 drives/cable. 5 SCA drives in a can--intelligent mounting chassis--w/1 cable to the controller. No more than 3 cables and 2 RAID5 sets per controller. Some cache on the controller (varies by model). Controllers/bus varies as does the bus type (SPD, PCI, PCI-X). There's no meaningful benchmark I can provide except that I can say it's good for thousands of real-world I/Os of varying sizes (8-64K) per second. With 14GB RAM in the main machine and OS/400's memory model & caching algorithms, I generally see >95% cache hits.

 

[mubs]

Aah! The precise Fushigi! I hear you, but the issue in this post was SCSI drives, SCSI controllers and transfer rates. As such, the host, controller cache and OS are immaterial.

I've never personally used SCSI, so pardon my ignorance and correct me if I'm wrong. If you have an 8-drive RAID-5 SCSI array, since they share a cable, at any given instant of time, only one drive can be transferring data to the controller, right? But since SCSI is efficient (compared to ATA, for instance), the "handshake & lock-on-the-connection" sequence, and the "goodbye" sequence can be executed rapidly. Since the controller can "time-slice" so quickly between the drives, the effect is one of apparent simultaneous data transfer (again, comparatively). This is what Coug seems to be saying, and this is my understanding as well.

So, as Blake has pointed out, sticking too many drives on one cable can bring performance down because the controller has to time-slice/service more drives.

If I'm generally making sense than I guess in the real world where they have these multi-terabyte storage systems they have lotsa controllers. If I'm talking rubbish, please enlighten me.

 

[blakerwry]

From what I understand you've got it pretty close.

The only thing that I would add is that on a SCSI controller you can request data from a drive, disconnect from it and pull data off another drive, then reconnect to the 1st drive and grab the data once it's in the drive's cache.

In ATA world you can request data from a drive, but have to stay connected to it until the data has been read and finished transfered to the controller before you can make a request from a different drive.

The SCSI way can greatly minimize time wasted during seek operations.. and of course there is TCQ/out of order delivery in SCSI land.

But S-ATA solves both these problems.

 

[mubs]

I guess you're right in that SATA can be pretty competitive with SCSI assuming the drives are similar (RPM, TCQ, etc.). But I think SAS will get the upper again when it comes out, no?

 

[Fushigi]

Aah! The precise Fushigi! I hear you, but the issue in this post was SCSI drives, SCSI controllers and transfer rates. As such, the host, controller cache and OS are immaterial.

Transfer rates are practically immaterial in OS/400 land. IOs/sec is what matters. In a transaction processing environment, the system does lots of very small I/Os and relatively few large ones. Large I/O requests are typical only when backing up & restoring.

Even index builds, where a large file is indexed, won't necessarily involve large transfers as the indexing algorithm may not be reading the file sequentially (sounds counter-intuitive but it's true). In my experience index builds are typically more CPU- than disk-intensive because of the complexity of the index criteria. Also, the file read pattern may further be influenced by the use of SMP for the index build process.

 

[blakerwry]

I guess you're right in that SATA can be pretty competitive with SCSI assuming the drives are similar (RPM, TCQ, etc.). But I think SAS will get the upper again when it comes out, no?

SAS supports S-ATA and more. It will be superior to S-ATA, there is no doubt. As long as it is offered at a reasonable price i see it as being the preferred interface.