PIII 550 variations

[Nick Bastin]

>(And, you _share interrupts_?  For your _drives_?  Ay-ay-ay.  Again,
>best of luck to you.)

Hey, I know exactly how the driver works, and I have no qualms with this.
If it starts doing something I don't like, I'll fix it.  On vastly inferior
hardware architectures (i.e. x86), one often has to resort to sharing
valuable system resources, like IRQs, to get by.  I've had SCSI systems use
more IRQ's than my ATA systems, so I don't see where there's a real
downside to ATA here.  Quite a number of SCSI controllers out there will
gobble up a few extra IRQ's when they need them to get async access to
drives - it's just that you don't notice it if you're not paying attention
(or don't write device drivers).

When I start suffering performance degradation because of a lack of
available IRQs on the ring, then I'll change the way I configure my
machines, but I haven't seen that as of yet, with any controller that I've
used.  I have some ethernet controllers which have a problem with this, but
I generally stay away from them, as IRQ sharing is something that is almost
an absolute necessity on ethernet cards.

>> Some of my clients are moving from SCSI to ATA on their network server
>> systems because of the costs, and RAID gives them the reliability that
>> they need.  Speed is not an issue because of single-drive channels and
>> large caches.
>
>Indeed, RAID on ATA would be the rock-bottom-priced way of getting large
>filesystem sizes with redundancy.  If you don't mind the rest of the
>baggage that comes with it.

I'm not sure what all of this 'baggage' is referring to.  It's kind of a
wide ranging generalization that people who are SCSI zealots tend to make
about ATA.  Yes, ATA is not SCSI, and yes, it putting more than one drive
on a channel is usually a mistake, but for getting lots of fairly fast
redundant space, it's not bad.

>> ATA RAID is frequently faster than non-RAID SCSI on reads, although
>> SCSI RAID, where appropriate, is still a killer beast (The ICP RAID
>> controllers *rock*).
>
><shrug>  If I want speed, I go with hardware RAID, rather than any form
>of software RAID.  But I doubt that your statement is even correct under

Who said anything about software RAID?  People do make ATA RAID
controllers, you know (and I'm not talking about the crap from Promise,
either...).  3ware makes a fairly respectable ATA RAID controller, although
at this point it only does mirroring, and not RAID 5.

>realistic test conditions.  Most people who do such benchmarks
>inadvertantly emulate single-tasking, single-thread, single-user
>conditions for their tests, along with other distortions.

For my raw benchmarking, this is pretty much exactly what I do.  There's a
reason for that: I'm interested in knowing the absolutely best case
scenario for this drive+controller combo.  It's a test like this that can
tell me 'don't bother running any more tests, because this
(drive/controller) sucks'.  Then you go and run the heavy database
transaction test, and see where that gets you.  ATA has performed well
enough for the tasks that I'm asking it to do on the systems I put it in.
When it doesn't perform well enough, it's time for SCSI.

>But, I'm glad you're happy with what you use, and I hope your clients
>are happy, too.

They seem to be at this point.  We've actually had more reliable systems
with ATA than SCSI at one location, but I'm making very clear that I don't
believe this to be because ATA is generally more reliable.  Obviously, I
have some issues with ATA not being hot-swap in any way, but 5 minutes of
downtime to replace a drive (on your own timeline) is still better than
having your only drive die and having to restore from backup.  With the
driving motivation in all industries to cut costs without degrading
service, businesses are looking wherever they can to make up some dollars,
so I've helped several eliminate expensive SCSI solutions where they
weren't needed.  Of course, all of those customers still have expensive
SCSI solutions in place, because, at the moment, they're the only solution
for the work that they do.  FC-AL may become a choice down the line, but it
is no cheaper than SCSI at this point, although faster.

>> I think there's an inherent flaw in the nature of this discussion, that
>> being that you apparently don't think I know anything about drive
>> technology...
>
>That bit of bait was just _enormously_ tempting, Nick, but I'm going to
>pass.

Aww shucks, and I thought we could have a slightly more entertaining
flamewar than the standard M$ drivel that passes around.  :-)


--
Nick Bastin
Software Developer
OPNET Technologies