SATA or SCSI drives - Multiple Read/write speeds.

[Mark Hahn]

| read the reviews and the hype about SATA being better than IDE/ATA and 
| almost as good as SCSI, even better in a couple of areas.

<sigh>


| I have talked to our computer people but they don't have enough 
| experience with SATA drives to give me a straight answer.

there's not THAT much to know.

SCSI:	pro: a nice bus-based architecture which makes it easy to put
	many disks in one enclosure.  the bus is fast enough to
	support around 3-5 disks without compromising bandwidth
	(in fact, you'll probably saturate your PCI(x) bus(es) first
	if you're not careful!) 10 and 15K RPM SCSI disks are common, 
	leading to serious advantages if your workload is latency-dominated
	(mostly of small, scattered, uncachable reads, and/or synchronous
	writes.)  5yr warrantees and 1.2 Mhour MTBF are very comforting.

	con: price.  older (pre Ultra2) disks lack even basic CRC protection.
	always lower-density than ATA; often hotter, too.  (note that the 
	density can actually negate any MTBF advantage!)

ATA:	pro: price.  massive density (and that means that bandwidth is 
	excellent, even at much lower RPM.)  ease of purchase/replacement;
	ubiquity (and cheapness) of controllers.

	con: probably half the MTBF of SCSI, 1yr warrantee is common, 
	though the price-premium for 3yr models is small.  most disks are
	5400 or	7200 RPM so latency is potentially a problem (though there is
	one line of 10K RPM'ers but at close to SCSI prices and density).

PATA:	pro: still a bit cheaper than SATA.  PATA *does* include tagged 
	command queueing, but it's mostly ignored by vendors and drivers.

	con: cabling just plain sucks for more than a few disks (remember:
	the standard STILL requires cable be <= 18" of flat ribbon).

SATA:	pro: nicer cable, albeit not bus or daisy-chain (until sata2);
	much improved support for hot-plug and TCQ.

	con: not quite mainstream (price and availability).  putting many
	in one box is still a bit of a problem (albeit also a power problem
	for any kind of disk...)

I have no idea what to make of the roadmappery that shows sata merging with 
serial-attached scsi in a few years.

| My concern is regarding multiple disk read/writes.  With IDE, you can 
| wait for what seems like hours while data is being read off of the HD. 

nah.  it's basically just a design mistake to put two active PATA disks 
on the same channel.  it's fine if one is usually idle (say, cdrom or 
perhaps a disk containing old archives).  most people just avoid putting 
two disks on a channel at all, since channels are almost free, and you 
get to ignore jumpers.


|   I want to know if the problem is still as bad with SATA as the 
| original ATA drives?  Will the onboard RAID speed up access?

there was no problem with "original" disks.  and raid works fine, up until
you saturate your PCI bus...


| I know that throughput on large files is close and is usually related 
| to platter speed.  I am also pleased that the buffers is now 8mb on 
| all the drives I am looking at.

one of the reasons that TCQ is not a huge win is that the kernel's cache
is ~500x bigger than the disk's.  however, it's true that bigger ondisk cache
lets the drive better optimize delayed writes within a cylinder.  for non-TCQ
ATA to be competitive when writing, it's common to enable write-behind
caching.  this can cause data loss or corruption if you crash at exactly the 
right time (paranoids take note).


| Main issue is writing and reading swap on those really large files and 
| how it affects other work.

swap thrashing is a non-fatal error that should be fixed, 
not band-aided by gold-plated hardware.

finally, I should mention that Jeff Garzik is doing a series of good new SATA
drivers (deliberately ignoring the accumulated kruft in the kernel's PATA
code).  they plug into the kernel's SCSI interface, purely to take advantage 
of support for queueing and hotplug, I think.

regards, mark hahn.

_______________________________________________
Beowulf mailing list, Beowulf at beowulf.org
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf