Data Storage - What am I doing wrong ??? Or is Adaptec 21610SA just a crappy RAID card ?

Author

What am I doing wrong ??? Or is Adaptec 21610SA just a crappy RAID card ?

news.tele.dk

2004-11-27, 5:47 pm

Hi,

We've bought the following server:

2 x Xeon 3.2Ghz 1mb lvl2 cache
Intel Server Board SE7320SP2LX
4 Gb of DDR400 REG/ECC
12 x +9 SATA, 120GB, 8MB, Fluid (in hotswap casings)

And put in an Adaptec 21610SA + battery option.

The server should do massive SQL-database transactions.

Just to test the setup we created on big stripe with all the disk's ....

But no matter what we cannot get read/write performance to exeed 100mb/sec
Considering that we can do around 55mb/sec on just one of the disk's
(configured as a single volume),
we consider this SUB-optimal...

Are we doing something wrong or is it just a very crappy card ???
We are sure it is mounted in a PCI-X (66Mhz / 64 bit) slot, so that's not
it.

I've also tested the system with bonnie :

Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
dhcp157.rgm-int. 8G 38581 98 83689 46 34724 17 30641 65 73920 23 571.3 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 2885 95 +++++ +++ +++++ +++ 2905 99 +++++ +++ 8293 98 dhcp157.rgm
int. dk,8G,38581,98,83689,46,34724,17,30641,6
5,73920,23,571. 3,1,16,2885,95,+++++,+++,+++++,+++,2905,
99,+++++,+++,8293,98

AAAAArrhhhggggggggg money out the window....

Charles Morrall

2004-11-28, 7:45 am

"news.tele.dk" <no@email.dk> skrev i meddelandet
news:41a91890$0$292$edfadb0f@dread11.news.tele.dk...
> Hi,
>
> We've bought the following server:
>
> 2 x Xeon 3.2Ghz 1mb lvl2 cache
> Intel Server Board SE7320SP2LX
> 4 Gb of DDR400 REG/ECC
> 12 x +9 SATA, 120GB, 8MB, Fluid (in hotswap casings)
>
> And put in an Adaptec 21610SA + battery option.
>
> The server should do massive SQL-database transactions.
>
I wouldn't recommend using SATA drives for online transactions, assuming
that's what you intend.
Using SCSI drives is what I would recommend for I/O intensive applications.

> Just to test the setup we created on big stripe with all the disk's ....
>
> But no matter what we cannot get read/write performance to exeed 100mb/sec
> Considering that we can do around 55mb/sec on just one of the disk's
> (configured as a single volume),
> we consider this SUB-optimal...
>
What is your target bandwidth? Also, are you sure high bandwidth is what you
need? To me it sounds like you're going to need IOPS (I/O per second). I'm
not sure what specific SQL engine you'll be using, but generally SQL uses an
I/O size of 2-8 kB for online transactions. Data warehouse is another
matter.
I don't have any figures on-hand what kind of I/O rate a single SATA drive
can do while keeping a reasonable response time (20 ms being the maximum
value I've learned) but considering the drive's specs are 7,2 krpm and
average seek 9.3 ms (taken from the data sheet of a Maxtor DiamondMax Plus
9) I don't expect this drive to be able to handle more than maybe 100-120
IOPS in a random r/w I/O pattern. Let's for arguments sake say it can
deliver up to 200 IOPS, and each I/O is 8kB. The total bandwidth would then
be 200*8*12 (12 is the number of drives in your setup) = 19.2 MB/s. This is
of course not factoring in RAID overhead.

> Are we doing something wrong or is it just a very crappy card ???
> We are sure it is mounted in a PCI-X (66Mhz / 64 bit) slot, so that's not
> it.
No, most likely not.

>
> I've also tested the system with bonnie :
[snip]
Sorry, I can't interpret the output from bonnie.

>
> AAAAArrhhhggggggggg money out the window....
>
Possibly, but it might depend on what you consider "massive SQL-database
transactions". Then again, in my experience many on-line SQL systems I've
delivered the disk subsystem to hardly uses any disk resources during normal
operation. Most transactions are handled in RAM, and never see the disks.
RAM being so cheap today, it makes good sense cramming as much memory into
the host and not worry about the disk subsystem. Perhaps this is what you'll
see too.
Good luck!
/charles

Arno Wagner

2004-11-28, 7:45 am

In comp.sys.ibm.pc.hardware.storage news.tele.dk <no@email.dk> wrote:
> Hi,

> We've bought the following server:

> 2 x Xeon 3.2Ghz 1mb lvl2 cache
> Intel Server Board SE7320SP2LX
> 4 Gb of DDR400 REG/ECC
> 12 x +9 SATA, 120GB, 8MB, Fluid (in hotswap casings)

> And put in an Adaptec 21610SA + battery option.

> The server should do massive SQL-database transactions.

> Just to test the setup we created on big stripe with all the disk's ....

> But no matter what we cannot get read/write performance to exeed 100mb/sec
> Considering that we can do around 55mb/sec on just one of the disk's
> (configured as a single volume),
> we consider this SUB-optimal...

> Are we doing something wrong or is it just a very crappy card ???
> We are sure it is mounted in a PCI-X (66Mhz / 64 bit) slot, so that's not
> it.

I have recently had bad experiences with an adaptex SATA raid
card for 8 disks. Bedises being unreliable and having unusable
software, it was also quite slow (66MHz/64bit PCI). I how have
the 8 disks on two promise 150TX4 with software-RAID5 (linux 2.6.9)
and that is faster!

I would say the card is overpriced trash. 3ware has a good name,
maybe try their cards. You can also try a pair of the promise
SX8 cards and software-RAID.

> AAAAArrhhhggggggggg money out the window....

Yes, I felt that way too. Adaptec is not getting any momey from
me for the next decade or so. Their SATA producst are a rip-off
IMO.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus

news.tele.dk

2004-11-28, 5:45 pm

> I wouldn't recommend using SATA drives for online transactions, assuming
> that's what you intend.
> Using SCSI drives is what I would recommend for I/O intensive
> applications.
>

SATA was chosen based on cost/benefit.
We figured we could buy approx. 4 times the amount of SATA disks
compared to SCSI.

Some of Tom's hardware recent tests was very promissing abount SATA
compared to SCSI...

> What is your target bandwidth? Also, are you sure high bandwidth is what
> you need? To me it sounds like you're going to need IOPS (I/O per second).
> I'm not sure what specific SQL engine you'll be using, but generally SQL
> uses an I/O size of 2-8 kB for online transactions. Data warehouse is
> another matter.

We don't have a target bandwidth, the system is bought to host a rather new
product, and the load right now is rather low.
The server can actually easy handle the current load, but when it first is
set in production (at an external hosting partner),
you know how hard it is to upgrade, so we would like it to last as long as
possible = maximize the current configuration.

So we could live with the current configuration... but if we could get the
same I/O speed for less money, why buy the
top-of-the-line-adaptec-sata-card ??? money out the window I say.

Further more, we expect to buy two machines and have the partitions of the
server (linux) be mirrored
via http://www.drbd.org/ (via a crossed GLAN cable), so a bad IO card is
actually two :-)

> I don't have any figures on-hand what kind of I/O rate a single SATA drive
> can do while keeping a reasonable response time (20 ms being the maximum
> value I've learned) but considering the drive's specs are 7,2 krpm and
> average seek 9.3 ms (taken from the data sheet of a Maxtor DiamondMax Plus
> 9) I don't expect this drive to be able to handle more than maybe 100-120
> IOPS in a random r/w I/O pattern. Let's for arguments sake say it can
> deliver up to 200 IOPS, and each I/O is 8kB. The total bandwidth would
> then be 200*8*12 (12 is the number of drives in your setup) = 19.2 MB/s.
> This is of course not factoring in RAID overhead.

That's why we bought the server with a fair amount of RAM, we should be able
to have the
currently active database objects in RAM, and a fair speed when seeking in
the "archives" (which is actually also your later stated point)

The battery option should take care of I/O writes.

> Possibly, but it might depend on what you consider "massive SQL-database
> transactions". Then again, in my experience many on-line SQL systems I've
> delivered the disk subsystem to hardly uses any disk resources during
> normal operation. Most transactions are handled in RAM, and never see the
> disks. RAM being so cheap today, it makes good sense cramming as much
> memory into the host and not worry about the disk subsystem. Perhaps this
> is what you'll see too.

I've examined benchmarks on other cards posted on the net, unfortunaly no
one
has tested the 21610SA against other cards (I wonder why?)

We should be able to get at least 400-600 mb/sec bandwidth to the disk
system.

I can see that our server-supplier also sells 3Ware, we will try to buy the
12
port SATA (9500) card next week, I wonder why they didn't mentioned all this
to us when we bought the system.

If I get the time I'll maybe post the tests.

mvh,
Carsten

Rita Ä Berkowitz

2004-11-28, 5:45 pm

news.tele.dk wrote:
>
> SATA was chosen based on cost/benefit.
> We figured we could buy approx. 4 times the amount of SATA disks
> compared to SCSI.

Yep, you got great cost savings without any benefits by going SATA. You
spent a good chunk of change on all your other hardware to degrade it back
to a gamer's machine or an eMachine for the sake of saving a few bucks.
That machine will only see it's full potential when you put U320 SCSI in it.

> Some of Tom's hardware recent tests was very promissing abount SATA
> compared to SCSI...

Again, another victim of the hype, propaganda, and other bullshit one finds
at Tom's Hardware.

Scrap the SATA garbage and get what you want in the first place, U320 SCSI.
Doing otherwise is looking for long-term problems and heartache. Good luck.

Rita
--
http://www.geocities.com/ritaberk2003/

news.tele.dk

2004-11-28, 5:45 pm

I think you are blaming it on the wrong component here...

I'm quite sure it's not the disks, it's the controller, the server can do
quite good
on one disk, but trying to spread the load out on more than two disks and
the controller(?) breaks...

So the deal is, i'm not complaining about SATA (yet), i'm complaining about
a quite obvious crappy controller card from Adaptec.

The story also contains a "side-story", my brother bought an external SATA
based raid unit, which is doing very well compared to other SCSI unit's
(especially
if you add "cost" to the metric).

The interface to the unit is SCSI, but internally it used SATA disks. So to
my
understanding I should be able to get the same, just "internal" based with
the
right equipment (controller card).

My belief is that the disk market will eventually go SATA, SATA technology
will
get better and better fewer SCSI disks will be sold, therefore get more and
more
expensive, and finally die.

best regards,
Carsten

"Rita Ä Berkowitz" <ritaberk2O04@aol.com> skrev i en meddelelse
news:10qk20pg1rsofd5@news.supernews.com...
> news.tele.dk wrote:
>
> Yep, you got great cost savings without any benefits by going SATA. You
> spent a good chunk of change on all your other hardware to degrade it back
> to a gamer's machine or an eMachine for the sake of saving a few bucks.
> That machine will only see it's full potential when you put U320 SCSI in
> it.
>
>
> Again, another victim of the hype, propaganda, and other bullshit one
> finds
> at Tom's Hardware.
>
> Scrap the SATA garbage and get what you want in the first place, U320
> SCSI.
> Doing otherwise is looking for long-term problems and heartache. Good
> luck.
>
>
> Rita
> --
> http://www.geocities.com/ritaberk2003/
>
>
>
>
>

Jesper Monsted

2004-11-28, 5:45 pm

"news.tele.dk" <no@email.dk> wrote in
news:41aa4ba0$0$56310$edfadb0f@dread16.news.tele.dk:

> My belief is that the disk market will eventually go SATA, SATA
> technology will
> get better and better fewer SCSI disks will be sold, therefore get
> more and more
> expensive, and finally die.

Nope. The market that uses SCSI now will use SAS-drives in the future and
FC will live for quite some time yet, although my guess is it'll get
replaced on the disk side of large arrays with SAS in the long run. PATA
will die and SATA will take the low- and lower midrange market.

--
/Jesper Monsted

Rita Ä Berkowitz

2004-11-28, 5:45 pm

news.tele.dk wrote:

> I think you are blaming it on the wrong component here...

Nope, SATA in general is to blame.

> I'm quite sure it's not the disks, it's the controller, the server
> can do quite good
> on one disk, but trying to spread the load out on more than two disks
> and the controller(?) breaks...

You're starting to see the joys of SATA. Unfortunately, it's costing you
time and money. Do a Google on SATA and this group and you'll quickly see
there are a lot of people in the same boat.

> So the deal is, i'm not complaining about SATA (yet), i'm complaining
> about a quite obvious crappy controller card from Adaptec.

You will be. SATA is all about novelty and hype. You get impressive specs
of storage and speed that costs pennies waved under your nose and you get
hooked. When you start putting it together and fall into the trap of lack
of reliability is when wish you never got involved with it. Believe me,
there are alot of people that bought into the hype and have since went back
to SCSI. It was a costly lesson.

> The story also contains a "side-story", my brother bought an external
> SATA based raid unit, which is doing very well compared to other SCSI
> unit's (especially
> if you add "cost" to the metric).

Using SATA for gaming machines and other novelty type boxes is the best
thing since sliced bread, but when you're running a business that depends on
reliability and uptime of their servers is where SATA costs you more money
in maintenance.

> The interface to the unit is SCSI, but internally it used SATA disks.
> So to my
> understanding I should be able to get the same, just "internal" based
> with the
> right equipment (controller card).

This is the whole illusion with SATA, it wants to be like SCSI, but can't.
This isn't something that can go both ways.

> My belief is that the disk market will eventually go SATA, SATA
> technology will
> get better and better fewer SCSI disks will be sold, therefore get
> more and more
> expensive, and finally die.

Nope, SCSI will never truly die. You might get variants of it (SAS), but it
will be with us for a long time in business class and enterprise machines.

Good luck, I hope you get it working.

Rita
--
http://www.geocities.com/ritaberk2003/

J. Clarke

2004-11-28, 5:45 pm

news.tele.dk wrote:

>
>
>
> SATA was chosen based on cost/benefit.
> We figured we could buy approx. 4 times the amount of SATA disks
> compared to SCSI.
>
> Some of Tom's hardware recent tests was very promissing abount SATA
> compared to SCSI...

All else being equal, SATA single drives seem to come pretty close to the
performance level of SCSI drives. But a high-end SATA drive is an
entry-level SCSI drive. Maybe that will change eventually. Right now SATA
has a way to go before it becomes a viable substitute even for PATA, let
alone SCSI.

>
> We don't have a target bandwidth, the system is bought to host a rather
> new product, and the load right now is rather low.
> The server can actually easy handle the current load, but when it first is
> set in production (at an external hosting partner),
> you know how hard it is to upgrade, so we would like it to last as long as
> possible = maximize the current configuration.
>
> So we could live with the current configuration... but if we could get the
> same I/O speed for less money, why buy the
> top-of-the-line-adaptec-sata-card ??? money out the window I say.

Whoever told you that Adaptec was "top of the line" is an idiot. Adaptec
RAID controllers have never worked particularly well and their ATA RAID
controllers even less so. See what IBM uses in their servers--you'll find
that it's Mylex, which IBM spun off to LSI Logic a while back. LSI Logic
has a nice family of SATA RAID controllers that might be worth a look. You
could also look at 3Ware, which specializes in SATA RAID. Since you're
using an Intel server board, an Intel RAID controller (designs are similar
but not identical to LSI IIRC) might be another viable option.

What you're going to have to do though is try the various boards in your
server until you find one that hits your performance objectives or have
gone through all of them.

> Further more, we expect to buy two machines and have the partitions of the
> server (linux) be mirrored
> via http://www.drbd.org/ (via a crossed GLAN cable), so a bad IO card is
> actually two :-)
>
>
> That's why we bought the server with a fair amount of RAM, we should be
> able to have the
> currently active database objects in RAM, and a fair speed when seeking in
> the "archives" (which is actually also your later stated point)
>
> The battery option should take care of I/O writes.

Huh? The only thing the battery option does is hold the data in the cache
in the event of a power outage until the power is restored. It has nothing
whatsoever to do with performance.

>
> I've examined benchmarks on other cards posted on the net, unfortunaly no
> one
> has tested the 21610SA against other cards (I wonder why?)
>
> We should be able to get at least 400-600 mb/sec bandwidth to the disk
> system.
>
> I can see that our server-supplier also sells 3Ware, we will try to buy
> the 12
> port SATA (9500) card next week, I wonder why they didn't mentioned all
> this to us when we bought the system.
>
> If I get the time I'll maybe post the tests.
>
> mvh,
> Carsten

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

news.tele.dk

2004-11-29, 2:45 am

"Rita Ä Berkowitz" <ritaberk2O04@aol.com> skrev i en meddelelse
news:10qkohv3gvnmp68@news.supernews.com...
> news.tele.dk wrote:
>
> You will be. SATA is all about novelty and hype. You get impressive
> specs
> of storage and speed that costs pennies waved under your nose and you get
> hooked. When you start putting it together and fall into the trap of lack
> of reliability is when wish you never got involved with it. Believe me,
> there are alot of people that bought into the hype and have since went
> back
> to SCSI. It was a costly lesson.

Yes it cost pennies, in Danish currency:

Maxtor Atlas 10K 146Gb = 3760,78
Maxtor DiamondMax 160Gb = 606,80

So what youre saying is: "The speed of SCSI disks is more than 6 times that
of SATA".
Eg. when we buy an array of disk with 2 SCSI disks it will match our SATA
array
with 12 disks (when we eventually get hold of a recent controller).

best regards,
Carsten

J. Clarke

2004-11-29, 7:45 am

news.tele.dk wrote:

> "Rita Ä Berkowitz" <ritaberk2O04@aol.com> skrev i en meddelelse
> news:10qkohv3gvnmp68@news.supernews.com...

One would like to know how many constitute "a lot" and a few names, but Rita
never has that.
[vbcol=seagreen]
> Yes it cost pennies, in Danish currency:
>
> Maxtor Atlas 10K 146Gb = 3760,78
> Maxtor DiamondMax 160Gb = 606,80
>
> So what youre saying is: "The speed of SCSI disks is more than 6 times
> that of SATA".
> Eg. when we buy an array of disk with 2 SCSI disks it will match our SATA
> array
> with 12 disks (when we eventually get hold of a recent controller).

Ignore Rita--the only tool she knows is SCSI so to her it's the perfect
solution to all problems including those for which it is totally
inappropriate. She's your basic troll. A fairly effective one I'll grant
her but she admits that she "plays" people rather than engaging in debate
over the actual merits of the technology.

However, that said, with enterprise storage you want all the speed you can
get but not at the cost of reliability. When the downtime to swap out a
drive can cost tens of thousands of dollars in lost productivity, the price
difference between an SATA and a SCSI drive is inconsequential if it saves
one outage over the course of a decade or so.

The only SATA drives that are designed specifically for enterprise storage
are the Western Digital Raptors. The Maxtor Maxlines are intended for
non-mission-critical servers. The Diamondmax you priced above is aimed at
desktop use and may or may not hold up in a heavily used server, but it's
best to assume it won't until proven otherwise.

> best regards,
> Carsten

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

V.S. Cottoncrotch

2004-11-29, 5:45 pm

Wasn't she the one that gracefully let you make an XXXXXXX out of yourself
in public when she called you to task for your spouting of misinformation?
As I remember, you were the one that claimed SATA superiority over SCSI.
Why the sudden change of heart? You have been proven wrong numerous times
by other members of this group who posted links to debunk your empty claims.
Even Rod embarrassed you.

"J. Clarke" <jclarke@nospam.invalid> wrote in message
news:cofa150lv0@news2.newsguy.com...

> Ignore Rita--the only tool she knows is SCSI so to her it's the perfect
> solution to all problems including those for which it is totally
> inappropriate. She's your basic troll. A fairly effective one I'll grant
> her but she admits that she "plays" people rather than engaging in debate
> over the actual merits of the technology.

Malcolm Weir

2004-11-29, 5:45 pm

On Sun, 28 Nov 2004 19:08:41 -0500, "J. Clarke"
<jclarke@nospam.invalid> wrote:

>All else being equal, SATA single drives seem to come pretty close to the
>performance level of SCSI drives. But a high-end SATA drive is an
>entry-level SCSI drive. Maybe that will change eventually. Right now SATA
>has a way to go before it becomes a viable substitute even for PATA, let
>alone SCSI.

[ Snip ]

>Whoever told you that Adaptec was "top of the line" is an idiot. Adaptec
>RAID controllers have never worked particularly well and their ATA RAID
>controllers even less so. See what IBM uses in their servers--you'll find
>that it's Mylex, which IBM spun off to LSI Logic a while back. LSI Logic
>has a nice family of SATA RAID controllers that might be worth a look. You
>could also look at 3Ware, which specializes in SATA RAID. Since you're
>using an Intel server board, an Intel RAID controller (designs are similar
>but not identical to LSI IIRC) might be another viable option.

I concur with this. In particular, having built large RAID systems
for a living, I'll state that it is utterly irrelevant to the consumer
what the back-end interface is. You should not care if the disks are
P-ATA, S-ATA, SAS, Parallel SCSI, Fibre Channel, or even good old SSA!

[ Actually, I could make a good argument that of those, Parallel SCSI
is possibly the worst choice architecturally, due to the shared bus
making it possible for a failing drive to influence it's neighbors,
which is not nice, plus the limited options when throwing resets
around: if you want to reset one drive, you can try and send it a
reset message, but if it doesn't respond, you have to whack the bus
and reset all the others on that bus. Against which, the mainstream
SCSI devices -- Parallel and Fibre Channel, which is just as much SCSI
and Parallel SCSI is -- tend to be higher performance, have more
sophisticated feature sets, and have higher reliability goals and
specs. Bottom line is that, today, FC is the "price-no-object" winner
]

Granted, some of those offer features that others don't, but in
reality the only one you care about is command tagged queueing. If a
disk implements CTQ at all (and the RAID controller uses it), you're
set.

To the original poster, I'd point out the existence of several
FibreChannel-to-SATA RAID systems that perform very nicely at their
price point, so SATA isn't the problem. And Adaptec's RAID offerings
have been notoriously, umm, low-end. AFAICT, they are positioned
against the Promise thingies, which are so low-end that they don't
actually do anything in hardware!

I've heard good things about 3Ware's SATA solutions, so I'd be
interested in the results of you trying those.

Malc.

Rita Ä Berkowitz

2004-11-29, 5:45 pm

news.tele.dk wrote:
>
> Yes it cost pennies, in Danish currency:
>
> Maxtor Atlas 10K 146Gb = 3760,78
> Maxtor DiamondMax 160Gb = 606,80
>
> So what youre saying is: "The speed of SCSI disks is more than 6
> times that of SATA".
> Eg. when we buy an array of disk with 2 SCSI disks it will match our
> SATA array
> with 12 disks (when we eventually get hold of a recent controller).

What I am saying is you bought some respectable hardware at a premium price
to accomplish a specific job. You castrated the system by anchoring it with
SATA and you are now seeing the pitfalls. I gave you practical real world
advice from experience that is tough to accept because you have a good
investment in SATA. My suggestion of SCSI doesn't look appealing because of
the initial cost. When you factor in ease of deployment, reliability,
longevity, and performance you quickly realize it pays for itself in short
order.

A few people and a resident troll gave you a few options. I gave you my
opinion on what to do, go SCSI and don't look back. The troll gave you a
typical answer of throwing hardware at it till you get the results you want.
Does that sound logical to you? Does that sound like a suggestion from
someone that has real world experience? Here's his quote

"What you're going to have to do though is try the various boards in your
server until you find one that hits your performance objectives or have
gone through all of them"

This is great advice if you have a source for unlimited hardware that isn't
going to cost you anything. Sure, take this route and spend another grand
or two and you will be right were you could have been in the first place
without the performance, SCSI.

I apologize for sounding so harsh, but this is your baby. When it takes a
crap, it's you that has the aggravation, expense, and egg on your face, not
me. I've been down this road many times with customers that bought into the
SATA crap pushed on them by inexperience hardware pushers and bailed them
out for a substantial price.

If you are really insistent on using SATA find someone that has a server
deployed that meets your specs and pick their brain for ideas of what
hardware to buy before you spend any more. Good luck in your endeavors.

Rita

--
http://www.geocities.com/ritaberk2003/

Rita Ä Berkowitz

2004-11-29, 5:45 pm

Nik Simpson

2004-11-29, 5:45 pm

J. Clarke wrote:
> news.tele.dk wrote:
>
>
> Huh? The only thing the battery option does is hold the data in the
> cache in the event of a power outage until the power is restored. It
> has nothing whatsoever to do with performance.

I'm guessing he's got write-thru cache enabled on the RAID controller and
believes that putting a battery backup for teh cache will allow him to
enable write caching. Of course his battery backup doesn't help if he gets a
RAM error/failure in the cache ;-)

--
Nik Simpson

Tim Boyer

2004-11-29, 5:45 pm

On Mon, 29 Nov 2004 17:39:11 -0500, "Rita Ä Berkowitz" <ritaberk2O04@aol.com>
wrote:

>news.tele.dk wrote:
>
>What I am saying is you bought some respectable hardware at a premium price
>to accomplish a specific job. You castrated the system by anchoring it with
>SATA and you are now seeing the pitfalls. I gave you practical real world
>advice from experience that is tough to accept because you have a good
>investment in SATA. My suggestion of SCSI doesn't look appealing because of
>the initial cost. When you factor in ease of deployment, reliability,
>longevity, and performance you quickly realize it pays for itself in short
>order.
>

<delurking>

In about six months, I'm going to be in the market for a 2TB system, and will
have to make some of the same choices. Rita, _why_ is SCSI so much better than
SATA?

Thanks much,

--
tim boyer
tim@denmantire.com

Rita Ä Berkowitz

2004-11-30, 2:45 am

Tim Boyer wrote:
>
> In about six months, I'm going to be in the market for a 2TB system,
> and will have to make some of the same choices. Rita, _why_ is SCSI
> so much better than SATA?

Tim, not knowing exactly what your requirements are, I'll just repeat in the
simplest terms what I said in a previous post, "When you factor in ease of
deployment, reliability, longevity, and performance you quickly realize it
pays for itself in short order." That said, depending on your requirements
SATA might be better for you if you have minimal demands and expectations.

Rita
--
http://www.geocities.com/ritaberk2003/

Eric Gisin

2004-11-30, 2:45 am

"Rita Ä Berkowitz" <ritaberk2O04@aol.com> wrote in message
news:10qns3vhd6ook15@news.supernews.com...
>
> Rita
> --
> http://www.geocities.com/ritaberk2003/
>
>
Is that a picture of you?

Tim Boyer

2004-11-30, 7:45 am

On Tue, 30 Nov 2004 10:03:46 +0200, Toomas Soome <Toomas.Soome@microlink.ee>
wrote:

>Tim Boyer wrote:
>
>current data transfer rates (lets not argue about possible future
>numbers, I have some but never done research for them):
>
>SATA: 150Mb/s (up to 1.5Gb/s?)
>SCSI: 320Mb/s
>SAS: 3Gb/s (roadmap up to 12Gb/s)?
>FC-AL: 2Gb/s (roadmap up to 10Gb/s ?)
>
>reliability:
>SCSI MTBF 1,200,000 hours, many SATA drives only run to 600,000 MTBF
>(http://searchstorage.techtarget.com...x294586,00.html)
>
>and some real numbers as well regarding to reliability:
>
>Deskstar 7K400, http://www.hitachigst.com/hdd/support/7k400/7k400.htm
>Error rate (non-recoverable) 1 in 10E14
>Start/stops (at 40° C) 50,000
>
>Ultrastar 15K147 http://www.hitachigst.com/hdd/support/15k147/15k147.htm
>Error rate (non-recoverable) 1 in 10E15
>Start/stops (at 40° C) 50,000
>
>in general, SATA will not replace SCSI anytime "soon", high end SCSI
>will still outperform SATA in many terms... but SATA does definitely
>have it's place as well.
>
>toomas

Thanks much, Toomas! I'm replacing a _very_ old Clariion, fairly lightly used,
so anything's gonna be an improvement. But I value reliability over
performance, and it looks like I'd be smart to stick with SCSI - for now, at
least.

--
tim boyer
tim@denmantire.com

Anton Rang

2004-11-30, 5:45 pm

"news.tele.dk" <no@email.dk> writes:
> So what youre saying is: "The speed of SCSI disks is more than 6 times that
> of SATA".

You're being overcharged for the SCSI disks....

But there are significant differences between SCSI and SATA in both
performance and reliability. They're not intrinsic to the interface,
rather to the cost structure of each.

SATA disks typically have less error checking internally than SCSI,
increasing the likelihood of undetected errors. Not a big deal if
you're working with 1 disk; more serious when you have 10 and
mission-critical data.

Some SATA disks don't have enough RAM to store the whole sector flaw
map at once. Random access across those disks can waste a whole
(extra) disk rotation to read the flaw map for a track. The drive
will cache some of these, and this works fine for home use, but in a
database environment this can be a 2x performance hit.

SCSI and FibreChannel disks, at this point, are engineered for
reliability, because the market buying them are customers who care
about that. SATA is engineered for low cost, period.

Anton

J. Clarke

2004-11-30, 5:45 pm

Toomas Soome wrote:

> Tim Boyer wrote:
>
> current data transfer rates (lets not argue about possible future
> numbers, I have some but never done research for them):
>
> SATA: 150Mb/s (up to 1.5Gb/s?)

No. 150 M_B_/sec. 3 Gb/sec hardware is shipping, not that it has any
real-world relevance. All allocated to a single device. No drive on the
market, SCSI or SATA, is capable of sustained transfers at anything close
to this rate, so it's adequate for any purpose.

> SCSI: 320Mb/s

Shared among up to 15 devices. No clear advantage to SCSI here unless you
give each device a separate channel, which gets hugely expensive very
quickly.

> SAS: 3Gb/s (roadmap up to 12Gb/s)?

Again, though, shared. And you're interchanging bits and bytes. That's
about 300 MB/sec.

> FC-AL: 2Gb/s (roadmap up to 10Gb/s ?)

Again, shared. And that's roughly 200 MB/sec when you allow for overhead.

> reliability:
> SCSI MTBF 1,200,000 hours, many SATA drives only run to 600,000 MTBF

This has nothing to do with SATA vs SCSI--look up the specs on WD Raptors
and you'll find that same 1,200,000 MTBF. If you want enterprise-class
storage get enterprise-class storage.

(http://searchstorage.techtarget.com...x294586,00.html)
>
> and some real numbers as well regarding to reliability:
>
> Deskstar 7K400, http://www.hitachigst.com/hdd/support/7k400/7k400.htm
> Error rate (non-recoverable) 1 in 10E14
> Start/stops (at 40° C) 50,000
>
> Ultrastar 15K147 http://www.hitachigst.com/hdd/support/15k147/15k147.htm
> Error rate (non-recoverable) 1 in 10E15
> Start/stops (at 40° C) 50,000

And if you look at the Raptor you'll find again 1 in 10E15.

> in general, SATA will not replace SCSI anytime "soon", high end SCSI
> will still outperform SATA in many terms... but SATA does definitely
> have it's place as well.

While this is true, it is not for any of the reasons you stated. SCSI does
have a few real advantages--there's a lot more in the way of
enterprise-class host adapters and array cabinets and the like available
for one thing. For another it allows _much_ longer cables. For a third,
for now the fastest SATA drives do not match the speed or capacity of the
fastest SCSI drives, and for 10K RPM SATA drives there's no second
source--that last is a marketing issue, not a technical one--there's no
reason that 15K RPM SATA drives can't be produced by multiple vendors, it's
just that so far they've decided not to.

Further, it's all rather far afield as the problem the OP is describing
isn't really addressed by any of this. His basic problem remains that he
got a substandard array controller.

> toomas

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

Peter

2004-11-30, 5:45 pm

> No. 150 M_B_/sec. 3 Gb/sec hardware is shipping, not that it has any
> real-world relevance. All allocated to a single device. No drive on the
> market, SCSI or SATA, is capable of sustained transfers at anything close
> to this rate, so it's adequate for any purpose.

Not true:
http://www.fcpa.com/products/hard-d...ifications.html
Data transfer rate To/from media 147 MB/s

>
> Shared among up to 15 devices. No clear advantage to SCSI here unless you
> give each device a separate channel, which gets hugely expensive very
> quickly.

Perfomance issues rarely relate to a sequential read/write speed alone. Most
likely they reflect poor random IO operations. Putting interface maximum
speed at the first place, is a mistake.

Nik Simpson

2004-11-30, 5:45 pm

Marcin Dobrucki wrote:
> Rita Ä Berkowitz wrote:
>
>
> Sorry, a question from a lurker. How does the SCSI interface
> improve reliability of the disks?

The SCSI interface per-se doesn't, but because SCSI & FC drives are designed
for "enterprise class" applications they go through a different & more
rigourous quality control process than consumer drives. It's this more
comprehensive QC that is responsible for better reliability rather than the
interface. So in the future there is no technical reason why the SATA drives
cannot meet the same reliability leves as SCSI, but in doing so they would
have to adopt the same QC & testing procedures which would erode the price
difference between them and other more "reliable" types of drive.

--
Nik Simpson

Peter

2004-11-30, 5:45 pm

Anton Rang

2004-11-30, 5:45 pm

"Peter" <peterfoxghost@yahoo.ca> writes:
>
> Not true:
> http://www.fcpa.com/products/hard-d...ifications.html
> Data transfer rate To/from media 147 MB/s

He said *sustained* data rates. You only get 147 MB/sec while you're on one
track. As soon as you have to switch heads or seek, there's a gap in the data
stream.

The only benchmark I could find on that drive in a couple of minutes
of hunting shows 80 MB/sec, which is still very good.

http://neasia.nikkeibp.com/wcs/leaf...asabt/fw/323039

-- Anton

flux

2004-12-01, 2:45 am

In article <41ac2963$1@news.infonet.ee>,
Toomas Soome <Toomas.Soome@microlink.ee> wrote:

> current data transfer rates (lets not argue about possible future
> numbers, I have some but never done research for them):
>
> SATA: 150Mb/s (up to 1.5Gb/s?)
> SCSI: 320Mb/s
> SAS: 3Gb/s (roadmap up to 12Gb/s)?
> FC-AL: 2Gb/s (roadmap up to 10Gb/s ?)

These numbers may also be irrelevant depending on how the data is being
accessed. If, for example, you are connected to a server over Ethernet,
even SATA is faster (taking the numbers at face value) than gigabit.

> reliability:
> SCSI MTBF 1,200,000 hours, many SATA drives only run to 600,000 MTBF
> (http://searchstorage.techtarget.com...p/0,294276,sid5 gci1001942
> tax294586,00.html)

What do those numbers actually mean? 1,200,000 hours is 136 years.

So this number taken at face value is pretty silly because it's
essentially saying it won't be until sometime in 22nd century before
just first SCSI hard disk anywhere on Earth fails!

Even not taken these numbers at face value, who is going to buy SATA
drives and keep them for several years? As long as they last through the
warranty period, you can just buy new ones. They are, after all, very
cheap. And you can bet the next generation will be bigger, better,
faster (e.g, SATA II), and cheaper.

flux

2004-12-01, 2:45 am

In article <313n27F383t0aU1@uni-berlin.de>,
"Nik Simpson" <n_simpson@bellsouth.net> wrote:

> The SCSI interface per-se doesn't, but because SCSI & FC drives are designed
> for "enterprise class" applications they go through a different & more
> rigourous quality control process than consumer drives. It's this more
> comprehensive QC that is responsible for better reliability rather than the
> interface. So in the future there is no technical reason why the SATA drives

Is this really the case?

Checking on Maxtor's site,
http://www.maxtor.com/portal/site/M...82eff9461400585
760b46068/?channelpath=/en_us/Support/Warranty%20Services/Warranty%20Peri
ods

It looks like the "plain" Maxtor's get a 3 year warranty and the
"high-end" get five, same as their SCSI counterparts.

It's not really obvious how this QC gets translated into a 2 year
difference.

Further, three years doesn't seem to be a really short life with respect
to computer hardware. Given how cheap SATA disks are, who would even
keep them around for that long, especially if you needed more space in
their place by that time?

flux

2004-12-01, 2:45 am

In article <ybt7jo35nye.fsf@isis.visi.com>, Anton Rang <rang@visi.com>
wrote:

> SATA disks typically have less error checking internally than SCSI,

How do you know this?

> increasing the likelihood of undetected errors. Not a big deal if
> you're working with 1 disk; more serious when you have 10 and

I don't get it. How is not a big deal if you are working with one disk?
If a single bit gets flipped and it happens to be in your OS's kernel
file or your government grant application worth a million dollars, it
could be very serious.

Malcolm Weir

2004-12-01, 2:45 am

On Wed, 01 Dec 2004 06:34:59 GMT, flux <support@fluxsoft.com> wrote:

>In article <41ac2963$1@news.infonet.ee>,
> Toomas Soome <Toomas.Soome@microlink.ee> wrote:
>
>
>These numbers may also be irrelevant depending on how the data is being
>accessed. If, for example, you are connected to a server over Ethernet,
>even SATA is faster (taking the numbers at face value) than gigabit.

Only if the network traffic has a 1:1 correspondence with the disk
traffic. This is very, very rare in large environments. Plus you
have forgotten that Ethernet is full-duplex...

And I'd note that *two* 1000BaseT networks deliver more bandwidth than
one...

>
>What do those numbers actually mean? 1,200,000 hours is 136 years.

It means that if you have 136 of them, one will fail every year during
their service life.

>So this number taken at face value is pretty silly because it's
>essentially saying it won't be until sometime in 22nd century before
>just first SCSI hard disk anywhere on Earth fails!

Not at all. The figure was calculated with (I'd bet) no more than a 5
year service life. You can predict *nothing* about what happens after
the service lifespan is exceeded. In other words, every single drive
could fail a week after it's fifth birthday without impacting that
number at all!

>Even not taken these numbers at face value, who is going to buy SATA
>drives and keep them for several years? As long as they last through the
>warranty period, you can just buy new ones. They are, after all, very
>cheap. And you can bet the next generation will be bigger, better,
>faster (e.g, SATA II), and cheaper.

The cost of managing large disk populations tends to make that idea a
very expensive one. Suppose you have 1,000 disks and a 3 year
expected life. That works out to replacing a disk every single
working day. Up the life to 5 years, and you get a day off every
week!

Malc.

J. Clarke

2004-12-01, 5:45 pm

flux wrote:

> In article <41ac2963$1@news.infonet.ee>,
> Toomas Soome <Toomas.Soome@microlink.ee> wrote:
>
>
> These numbers may also be irrelevant depending on how the data is being
> accessed. If, for example, you are connected to a server over Ethernet,
> even SATA is faster (taking the numbers at face value) than gigabit.
>
>
> What do those numbers actually mean? 1,200,000 hours is 136 years.
>
> So this number taken at face value is pretty silly because it's
> essentially saying it won't be until sometime in 22nd century before
> just first SCSI hard disk anywhere on Earth fails!

That's not the service life--it doesn't take wear into consideration. If
you have say 140 drives then you should expect one failure every year out
of that 140.

> Even not taken these numbers at face value, who is going to buy SATA
> drives and keep them for several years? As long as they last through the
> warranty period, you can just buy new ones. They are, after all, very
> cheap. And you can bet the next generation will be bigger, better,
> faster (e.g, SATA II), and cheaper.

For enterprise storage replacing drives every two years would be very
costly. The price of the drives is peanuts compared to the cost of
downtime.

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

J. Clarke

2004-12-01, 5:45 pm

flux wrote:

> In article <313n27F383t0aU1@uni-berlin.de>,
> "Nik Simpson" <n_simpson@bellsouth.net> wrote:
>
>
> Is this really the case?
>
> Checking on Maxtor's site,
> http://www.maxtor.com/portal/site/M...82eff9461400585
> 760b46068/?channelpath=/en_us/Support/Warranty%20Services/Warranty%20Peri
> ods
>
> It looks like the "plain" Maxtor's get a 3 year warranty and the
> "high-end" get five, same as their SCSI counterparts.

By that reasoning Hyundai makes the best car on Earth. Warranty length is
related to marketing concerns, not to durability.

> It's not really obvious how this QC gets translated into a 2 year
> difference.

It doesn't. Marketing decided that to sell drives in their target market
they needed a 5 year warranty, and they built the cost of that into the
price of the drive.

> Further, three years doesn't seem to be a really short life with respect
> to computer hardware. Given how cheap SATA disks are, who would even
> keep them around for that long, especially if you needed more space in
> their place by that time?

Any enterprise that was using them for mission-critical storage. Don't
assume that the enterprise market is like a home user who can shut his
machine down on a whim.

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

J. Clarke

2004-12-01, 5:45 pm

flux wrote:

> In article <ybt7jo35nye.fsf@isis.visi.com>, Anton Rang <rang@visi.com>
> wrote:
>
>
> How do you know this?
>
>
> I don't get it. How is not a big deal if you are working with one disk?
> If a single bit gets flipped and it happens to be in your OS's kernel
> file or your government grant application worth a million dollars, it
> could be very serious.

The more disks you have the more likely you'll get an error.

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

Peter

2004-12-01, 5:45 pm

> > reliability:
gci1001942[vbcol=seagreen]
>
> What do those numbers actually mean? 1,200,000 hours is 136 years.
>
> So this number taken at face value is pretty silly because it's
> essentially saying it won't be until sometime in 22nd century before
> just first SCSI hard disk anywhere on Earth fails!

You are completely wrong (did you ever studied statistics?).

Let me quote:
"MTBF is an abbreviation for Mean Time Between Failures.
MTBF is a measure of how reliable a product is. MTBF is usually given in
units of hours; the higher the MTBF, the more reliable the product is.
For electronic products, it is commonly assumed that during the useful
operating life period the parts have constant failure rates, and part
failure rates follow an exponential law of distribution. In this case, the
MTBF of the product can be calculated as:
MTBF = 1/(sum of all the part failure rates)
and the probability that the product will work for some time T without
failure is given by:
R(T) = exp(-T/MTBF)
Thus, for a product with an MTBF of 250,000 hours, and an operating time of
interest of 5 years (43,800 hours):
R = exp(-43800/250000) = 0.839289
which says that there is an 83.9% probability that the product will operate
for the 5 years without a failure, or that 83.9% of the units in the field
will still be working at the 5 year point."

It means that during 5 years, for a 1,000 disks in your enterprise,
36 disks will fail if MTBF is 1,200,000 hrs
or 70 disks will fail if MTBF is 600,000 hrs
or 136 disks will fail if MTBF is 300,000 hrs

Now, if every storage unit has RAID 1 (2 disks), and enterprise has 1,000
storage units,
1.3 storage units will fail if MTBF of each disk is 1,200,000 hrs
5 storage units will fail if MTBF of each disk is 600,000 hrs
18 storage units will fail if MTBF of each disk is 300,000 hrs
assuming that you are not paying attention (replacing) to dead disks. If you
replace dead drives at frequent intervals, reliabilty of RAID 1 storage
units will be even much higher.

Jesper Monsted

2004-12-01, 5:46 pm

"J. Clarke" <jclarke@nospam.invalid> wrote in
news:cokrhu0166f@news3.newsguy.com:

> For enterprise storage replacing drives every two years would be very
> costly. The price of the drives is peanuts compared to the cost of
> downtime.

And any decent storage system should handle the replacement just fine,
using spare drives and/or rebuilding the ones replaced. You're not using a
big shiny box as a raid0 device, are you?

--
/Jesper Monsted

flux

2004-12-02, 2:45 am

In article <cokri01166e@news3.newsguy.com>,
"J. Clarke" <jclarke@nospam.invalid> wrote:

>
> By that reasoning Hyundai makes the best car on Earth. Warranty length is
> related to marketing concerns, not to durability.

No, your analogy doesn't fly because warranties cost money if the drives
have a high-failure rate. The reason companies can offer warranties of
such lengths is because their products are least durable enough to make
it cost-effective.

The fact that SATA and SCSI have similar warranties clearly indicates
the companies have enough confidence in SATA that they consider it
durable.

A logical rebuttal might be that manufacturers could offer lifetime
warranties on SCSI drives because they are just that durable, but a
warranty that long doesn't make sense from a marketing point of view
because the manufacturers do want their customers to upgrade eventually.

>
> It doesn't. Marketing decided that to sell drives in their target market
> they needed a 5 year warranty, and they built the cost of that into the
> price of the drive.

It clearly does. If the failure rate for drives increases in the fourth
and fifth year, it will cost the company money to replace the broken
drives.

>
> Any enterprise that was using them for mission-critical storage. Don't
> assume that the enterprise market is like a home user who can shut his
> machine down on a whim.

This is also illogical. It's like saying you can't ever upgrade.

flux

2004-12-02, 2:45 am

In article <316g5qF3896noU1@individual.net>,
"Peter" <peterfoxghost@yahoo.ca> wrote:

> gci1001942
>
> You are completely wrong (did you ever studied statistics?).

Reread what I wrote carefully, and you will see that is quite correct.

flux

2004-12-02, 2:45 am

In article <cokrhu0166f@news3.newsguy.com>,
"J. Clarke" <jclarke@nospam.invalid> wrote:

> For enterprise storage replacing drives every two years would be very
> costly. The price of the drives is peanuts compared to the cost of
> downtime.

This seems to imply nobody ever buys new equipment.

flux

2004-12-02, 2:45 am

In article <gr0rq0153drf7fhg9didasoe8154nuerds@4ax.com>,
Malcolm Weir <malc@gelt.org> wrote:

> Only if the network traffic has a 1:1 correspondence with the disk
> traffic. This is very, very rare in large environments. Plus you
> have forgotten that Ethernet is full-duplex...

I don't know whether to interpret this as saying everyone is on a very
slow network or a very fast network. Those scenarios are probably very
rare, so either way, it supports my argument. SATA is plenty fast enough
on a server to handle clients are an ordinary Ethernet network.

Malcolm Weir

2004-12-02, 2:45 am

On Thu, 02 Dec 2004 07:21:47 GMT, flux <support@fluxsoft.com> wrote:

>In article <gr0rq0153drf7fhg9didasoe8154nuerds@4ax.com>,
> Malcolm Weir <malc@gelt.org> wrote:
>
>
>I don't know whether to interpret this as saying everyone is on a very
>slow network or a very fast network. Those scenarios are probably very
>rare, so either way, it supports my argument. SATA is plenty fast enough
>on a server to handle clients are an ordinary Ethernet network.

*Sigh* You don't get out much, do you?

Outside the trivial case of file and print serving, people use
applications like, say, databases.

Which means that a few bytes sent across the network (say, "SELECT x.y
where x.id = z and y.thing = 123") result in many, many disk accesses,
totalling gigabytes of IO.

Now, has it dawned on you that even the most rudimentary of network
servers has multiple NICs? Why do you think that is? Are server
manufacturers silly?

I strongly suspect that all your experience has been with the trivial
case, where you have (at most) a few file-sharing clients on a
network. In these case, you are right. But there's no money in that
market, since any fool can build such a system.

Where *hard* problems are, at least for those of us in
comp.arch.storage, it is assumed that the network problem is already
solved. Need 10GB/sec of network bandwidth and don't have a 10G
Ethernet? Simply trunk 10 1000BaseT nets to your switch! cisco (and
the like) can handle that part of the problem.

Secondly, "very rare" is relative. In terms of "raw number of
installations", you could be right. In terms of "Organizations with
an IT budget in excess of $100000 per year", you are wrong.

Guess who the vendors care about?

Malc.

Malcolm Weir

2004-12-02, 2:45 am

On Thu, 02 Dec 2004 07:13:57 GMT, flux <support@fluxsoft.com> wrote:

>In article <cokrhu0166f@news3.newsguy.com>,
> "J. Clarke" <jclarke@nospam.invalid> wrote:
>
>
>This seems to imply nobody ever buys new equipment.

No, it doesn't. It implies that enterprises would rather replace
drives every three years, not every two, and would rather replace them
every four years than every three, etc.

Are you being deliberately obtuse?

Malc.

Malcolm Weir

2004-12-02, 2:45 am

On Thu, 02 Dec 2004 07:12:26 GMT, flux <support@fluxsoft.com> wrote:

>In article <316g5qF3896noU1@individual.net>,
> "Peter" <peterfoxghost@yahoo.ca> wrote:
>
>
>Reread what I wrote carefully, and you will see that is quite correct.

No, it isn't. You claimed that the "mean time between failures" being
136 years is equivalent to the claim that the minimum time to failure
is 136 years.

I'll reduce it to terms simple enough for anyone: take an ordinary
dice. I hope you can see that the mean number of throws between
getting a "1" is 6, since if you toss it 60 times, you can expect to
see a "1" about 10 heads.

You've just claimed that it's essentially saying you won't see a "1"
until you've tossed the dice six times.

Which is nonsense. Try it and see.

Malc.

Malcolm Weir

2004-12-02, 2:45 am

On Thu, 02 Dec 2004 07:09:02 GMT, flux <support@fluxsoft.com> wrote:

[ Snip ]

>The fact that SATA and SCSI have similar warranties clearly indicates
>the companies have enough confidence in SATA that they consider it
>durable.

No, it doesn't. They *may* have that confidence (although when asked,
they contradict you, but what do they know?), but you are ignoring
other factors.

Ask any marketing professional about "take up" rates. For any offer,
service, or program that a manufacturer provides, some proportion of
customers won't take advantage of it even when they could. Sometimes
this is because they lose necessary documentation, other times because
they forget, and still more because they don't care about replacing
the failed unit with another equivalent unit (e.g. if you're going
through the hassle of replacing the thing, why not upgrade at the same
time?)

>A logical rebuttal might be that manufacturers could offer lifetime
>warranties on SCSI drives because they are just that durable, but a
>warranty that long doesn't make sense from a marketing point of view
>because the manufacturers do want their customers to upgrade eventually.

You call *that* "logical"?

The fact is that drives are designed with a service life in mind.
This allows them to be sealed units, with no replaceable filters, no
lubrication points, etc. This makes them cheaper.

(You know we used to have disks that had filters, lubrication, etc.,
right?)

[ Snip ]

>
>It clearly does. If the failure rate for drives increases in the fourth
>and fifth year, it will cost the company money to replace the broken
>drives.

Do you really believe that the same proportion of people take
manufacturers up on the warranty after (say) 3 years as do after 1
month?

>
>This is also illogical. It's like saying you can't ever upgrade.

Your version of "logic" is somewhat, umm, naive!

Malc.

Nik Simpson

2004-12-02, 7:45 am

flux wrote:
> In article <cokri01166e@news3.newsguy.com>,
> "J. Clarke" <jclarke@nospam.invalid> wrote:
>
>
> No, your analogy doesn't fly because warranties cost money if the
> drives have a high-failure rate. The reason companies can offer
> warranties of such lengths is because their products are least
> durable enough to make it cost-effective.

But they are basing their warranty calculations on how the drive is used,
and (with the exception of WD's 10K drives) they expect them to go into PC
devices which don't run 24x7, so the MTBF is expected to be stretched
because the drive is spending a good deal of its time doing very little or
powered down.

--
Nik Simpson

Nik Simpson

2004-12-02, 7:45 am

flux wrote:
> In article <gr0rq0153drf7fhg9didasoe8154nuerds@4ax.com>,
> Malcolm Weir <malc@gelt.org> wrote:
>
>
> I don't know whether to interpret this as saying everyone is on a very
> slow network or a very fast network. Those scenarios are probably very
> rare, so either way, it supports my argument. SATA is plenty fast
> enough on a server to handle clients are an ordinary Ethernet network.

"Plenty fast enough" varies considerably from one application to another.
Yes, SATA is fast enough for some types of application, but that doesn't
translate to fast enough for all applications.

--
Nik Simpson

Peter

2004-12-02, 7:45 am

> > You are completely wrong (did you ever studied statistics?).
>
> Reread what I wrote carefully, and you will see that is quite correct.

Yes, I did. You have said:
"So this number taken at face value is pretty silly because it's
essentially saying it won't be until sometime in 22nd century before
just first SCSI hard disk anywhere on Earth fails!"

No your understanding is NOT correct, MTBF number does not imply that!

Folkert Rienstra

2004-12-02, 8:45 pm

"J. Clarke" <jclarke@nospam.invalid> wrote in message news:coi5dq0pq8@news2.newsguy.com
> Toomas Soome wrote:
>
> No. 150 MB/sec. 3 Gb/sec hardware is shipping, not that it has any
> real-world relevance.

It has for concentrators/expanders/portmultipliers (whatever they call it).

> All allocated to a single device. No drive on the market, SCSI or SATA,
> is capable of sustained transfers at anything close to this rate, so it's
> adequate for any purpose.

Not if that drive is 1 of 4 hanging off a concentrator in a RAID configuration.

>
>
> Shared among up to 15 devices.

To 4 actually for simultanious access.
15 can be physically attached but aren't expected to run simultaniously.

> No clear advantage to SCSI here unless you give each device
> a separate channel, which gets hugely expensive very quickly.
>
>
> Again, though, shared.

Nope, unless we are talking of an expander.
[vbcol=seagreen]
> And you're interchanging bits and bytes. That's about 300 MB/sec.
>
>
> Again, shared. And that's roughly 200 MB/sec when you allow for overhead.
>
>
> This has nothing to do with SATA vs SCSI--look up the specs on WD Raptors
> and you'll find that same 1,200,000 MTBF. If you want enterprise-class
> storage get enterprise-class storage.
>
> (http://searchstorage.techtarget.com...x294586,00.html)
>
> And if you look at the Raptor you'll find again 1 in 10E15.
>
>
> While this is true, it is not for any of the reasons you stated. SCSI
> does have a few real advantages--there's a lot more in the way of
> enterprise-class host adapters and array cabinets and the like available
> for one thing. For another it allows _much_ longer cables. For a third,
> for now the fastest SATA drives do not match the speed or capacity of
> the fastest SCSI drives, and for 10K RPM SATA drives there's no second
> source--that last is a marketing issue, not a technical one--there's no
> reason that 15K RPM SATA drives can't be produced by multiple vendors,
> it's just that so far they've decided not to.
>
> Further, it's all rather far afield as the problem the OP is describing
> isn't really addressed by any of this. His basic problem remains that he
> got a substandard array controller.
>

Folkert Rienstra

2004-12-02, 8:45 pm

"J. Clarke" <jclarke@nospam.invalid> wrote in message news:cokrhu0166f@news3.newsguy.com
> flux wrote:
>
> That's not the service life--it doesn't take wear into consideration.

Of course it does.

> If you have say 140 drives then you should expect one failure every year
> out of that 140.

Only if it runs 24/7 and the MTBF is based on 24/7 POH.

>
>
> For enterprise storage replacing drives every two years would be very
> costly.

> The price of the drives is peanuts compared to the cost of downtime.

So you configure your system for minimal downtime based on redundancy,
not single drive MTBF.

Maxim S. Shatskih

2004-12-02, 8:45 pm

> have to make some of the same choices. Rita, _why_ is SCSI so much better
than
> SATA?

Drives themselves are better, SATA interface is used for medium-class models,
while SCSI is for high-end ones.

SCSI supports disconnects (parallel work of several drives on the same cable)
and tagged queue (the drive is aware of the IO request queue and can reorder it
itself using the information like rotation and actuator positions accessible to
firmware but not accessible to the OS).

ATA support for these features is pathetic, and not supported yet in many OSes
like Windows.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

J. Clarke

2004-12-03, 2:45 am

Maxim S. Shatskih wrote:

> than
>
> Drives themselves are better, SATA interface is used for medium-class
> models, while SCSI is for high-end ones.

What specific features or characteristics the WD Raptors as "medium-class"?

> SCSI supports disconnects (parallel work of several drives on the same
> cable)

SATA supports one drive per cable, so how would this be useful with SATA?

> and tagged queue (the drive is aware of the IO request queue and
> can reorder it itself using the information like rotation and actuator
> positions accessible to firmware but not accessible to the OS).
>
> ATA support for these features is pathetic, and not supported yet in many
> OSes like Windows.

I see. So what specific properties make SCSI command queuing superior to
both the command queuing methods available with SATA?
>

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

flux

2004-12-03, 2:45 am

In article <318m7jF385o5qU1@individual.net>,
"Peter" <peterfoxghost@yahoo.ca> wrote:

>
> Yes, I did. You have said:
> "So this number taken at face value is pretty silly because it's
> essentially saying it won't be until sometime in 22nd century before
> just first SCSI hard disk anywhere on Earth fails!"
>
> No your understanding is NOT correct, MTBF number does not imply that!
>
>

No, you are still misunderstanding. I was *intentionally* reading it as
a literal value.

flux

2004-12-03, 2:45 am

In article <r1mtq05he18rsmndcftua729m52fruiupa@4ax.com>,
Malcolm Weir <malc@gelt.org> wrote:

> On Thu, 02 Dec 2004 07:13:57 GMT, flux <support@fluxsoft.com> wrote:
>
>
> No, it doesn't. It implies that enterprises would rather replace
> drives every three years, not every two, and would rather replace them
> every four years than every three, etc.

How is three years any signficantly less costly than two?

flux

2004-12-03, 2:45 am

In article <s8ltq09m5arcc6vfhthdj5gh242rk0j9mc@4ax.com>,
Malcolm Weir <malc@gelt.org> wrote:

> Now, has it dawned on you that even the most rudimentary of network
> servers has multiple NICs? Why do you think that is? Are server
> manufacturers silly?

That's a very recent developlment. Even gigabit is relatively recent.

> I strongly suspect that all your experience has been with the trivial
> case, where you have (at most) a few file-sharing clients on a
> network. In these case, you are right. But there's no money in that
> market, since any fool can build such a system.

What other market is there?

> Where *hard* problems are, at least for those of us in
> comp.arch.storage, it is assumed that the network problem is already
> solved. Need 10GB/sec of network bandwidth and don't have a 10G
> Ethernet? Simply trunk 10 1000BaseT nets to your switch! cisco (and
> the like) can handle that part of the problem.

Again, this sounds very rare. Where are there disks fast enough to
saturate this much Ethernet?

flux

2004-12-03, 2:45 am

In article <o1Drd.83122$jE2.3165@bignews4.bellsouth.net>,
"Nik Simpson" <n_simpson@bellsouth.net> wrote:

> But they are basing their warranty calculations on how the drive is used,
> and (with the exception of WD's 10K drives) they expect them to go into PC
> devices which don't run 24x7, so the MTBF is expected to be stretched
> because the drive is spending a good deal of its time doing very little or
> powered down.

The Tivo I have attached to my TV streams video to disk 24/7. That's a
consumer appliance!

In an ordinary office environment, how would backups get accomplished if
the computers are running 24/7?

flux

2004-12-03, 2:45 am

In article <hjmtq0lr2jial9ngf2m0vd1v14ticogl0g@4ax.com>,
Malcolm Weir <malc@gelt.org> wrote:

> Ask any marketing professional about "take up" rates. For any offer,
> service, or program that a manufacturer provides, some proportion of
> customers won't take advantage of it even when they could. Sometimes
> this is because they lose necessary documentation, other times because
> they forget, and still more because they don't care about replacing
> the failed unit with another equivalent unit (e.g. if you're going
> through the hassle of replacing the thing, why not upgrade at the same
> time?)

Or it could simply be the case that the drives are more reliable than
you believe.

>
> You call *that* "logical"?

yes.

> Do you really believe that the same proportion of people take
> manufacturers up on the warranty after (say) 3 years as do after 1
> month?

No, they probably upgrade. But wait didn't someone just say the cost of
upgrading is peanuts compared to the cost of downtime.

Peter

2004-12-03, 7:45 am

> > Yes, I did. You have said:
>
> No, you are still misunderstanding. I was *intentionally* reading it as
> a literal value.

I don't think you will get anywhere with that sort of interpretation.

Maxim S. Shatskih

2004-12-03, 5:45 pm

> What do those numbers actually mean? 1,200,000 hours is 136 years.
>
> So this number taken at face value is pretty silly because it's
> essentially saying it won't be until sometime in 22nd century before
> just first SCSI hard disk anywhere on Earth fails!

No, this only means that each year 1 of 136 disks will fail

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

J. Clarke

2004-12-03, 5:45 pm

flux wrote:

> In article <s8ltq09m5arcc6vfhthdj5gh242rk0j9mc@4ax.com>,
> Malcolm Weir <malc@gelt.org> wrote:
>
>
> That's a very recent developlment. Even gigabit is relatively recent.
>
>
> What other market is there?

Are you really this ignorant?

>
> Again, this sounds very rare. Where are there disks fast enough to
> saturate this much Ethernet?

Are you familiar with the concept of "RAID"?

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

Anton Rang

2004-12-03, 5:45 pm

flux <support@fluxsoft.com> writes:
> In article <ybt7jo35nye.fsf@isis.visi.com>, Anton Rang <rang@visi.com>
> wrote:
>
>
> How do you know this?

*points out the window to the Seagate office down the road*

I work in storage; I talk with drive engineers (and RAID engineers).

-- Anton

Anton Rang

2004-12-03, 5:45 pm

"J. Clarke" <jclarke@nospam.invalid> writes:
>
> SATA supports one drive per cable, so how would this be useful with SATA?

Disconnect is a requirement for tagged queueing (otherwise you don't
get a chance to issue the other command, and the drive doesn't get to
transfer data for commands out-of-order). (It's also useful in the
SCSI shared bus environment, of course.)

> I see. So what specific properties make SCSI command queuing superior to
> both the command queuing methods available with SATA?

The original queueing method took an extra interrupt per I/O and added
lots of overhead for each command (according to Intel, anyway, I never
looked at that spec). The "Native Command Queueing II" is supposed to
be better.

A few differences I see immediately in looking at the spec --

SCSI command queueing supports 256 outstanding commands per target.
ATA command queueing supports 32 outstanding commands per target.

SCSI disconnect allows data to be transferred out-of-order (for instance,
start sending data at the sector under the drive head, then go back to
fill in the preceding sectors as the disk rotates back to them). This
can reduce latency, particularly for small multi-sector transfers.
ATA disconnect requires data to be transferred in-order.

SCSI command queueing supports an ordering model which allows the host
to specify high-priority commands, or commands whose order must be
maintained (important for databases). ATA command queueing does not
(hence ordered writes cannot use queueing).

SCSI command queueing allows commands to be aborted. It's not obvious
to me whether ATA command queueing allows this or not.

-- Anton

Malcolm Weir

2004-12-03, 5:45 pm

On Fri, 03 Dec 2004 07:22:31 GMT, flux <support@fluxsoft.com> wrote:

>In article <hjmtq0lr2jial9ngf2m0vd1v14ticogl0g@4ax.com>,
> Malcolm Weir <malc@gelt.org> wrote:
>
>
>Or it could simply be the case that the drives are more reliable than
>you believe.

Well, my beliefs are based on experience and direct conversations with
disk drive manufacturers.

What are yours based on?

>
>yes.

Figures.

It isn't.

Drives have a service life which is related to the MTBF, but is
different from it.

Here's a scenario that is, hopefully, simple enough even for you:

Taking your 1.2Mhour MTBF, that might mean:

Year 1: 1 out of every 150 drives fails. 95% of failed drives get
returned for replacement. Cost of replacement = 100% cost of new
drive.
Year 2: 1 out of every 146 drives fails. 90% of failed drives get
returned for replacement. Cost of replacement = 90% cost of new
drive.
Year 3: 1 out of every 142 drives fails. 85% get returned. Cost of
replacement = 80% cost of new drive.
Year 4: 1 out of every 135 drives fails. 75% get returned. Cost of
replacement = 60% of cost of new drive.
Year 5: 1 out of every 100 drives fails. 50% get returned. Cost of
replacement = 40% of cost of new drive.
Year 6: No one cares. 0% get returned. Cost of replacement n/a.

The numbers are, of course, entirely fictional, but they *are*
representative of what happens.

You are probably confused why the "cost of replacement" (to the
manufacturer) falls over time. There are two main reasons for this:
amortization of development cost over time versus the production
costs. If a manufacturer decides that a given drive has an effective
saleable lifespan of, say, 2 years, then *all* the development costs
have to be recovered in that time, since they won't be selling many
after that period. (They'll likely be selling a similar model, but it
won't be the same disk. Take the disk in a 20GB Ipod, which is either
a Toshiba MK2003GAL or MK2004GAL. Same functional specs, but the
latter is later, obviously).

The second reason why the replacement cost falls is that if you
replace a disk having a 5 year warranty after 2 years, the replacement
only carries a 3 year warranty.

>
>No, they probably upgrade.

Or.... can't find the paperwork/remember that they have a warranty...

>But wait didn't someone just say the cost of
>upgrading is peanuts compared to the cost of downtime.

Yes, it is. Welcome to the point. I hope you'll be very happy
together.

The cost of downtime dwarfs the cost of the upgrade. Just as the cost
of installing cabling dwarfs the cost of the cable. So if you're
going to mess around with doing either, you may as well install the
more expensive while you're at it!

One positive note from this extremely silly thread: I went and
discovered that a little dead notebook drive that I bought two years
ago still has a warranty. So it's off to Hitachi with it!

(It was replaced several months ago. I just hadn't got around to
tossing it... luckily!)

Malc.

Malcolm Weir

2004-12-03, 5:45 pm

On Fri, 03 Dec 2004 07:19:38 GMT, flux <support@fluxsoft.com> wrote:

>In article <o1Drd.83122$jE2.3165@bignews4.bellsouth.net>,
> "Nik Simpson" <n_simpson@bellsouth.net> wrote:
>
>
>The Tivo I have attached to my TV streams video to disk 24/7. That's a
>consumer appliance!

Yes. What's your point?

Do you think that *every* Tivo does that?

>In an ordinary office environment, how would backups get accomplished if
>the computers are running 24/7?

A good question. One that professionals have been dealing with for
decades.

We've solved it.

Malc.

Malcolm Weir

2004-12-03, 5:45 pm

On Fri, 03 Dec 2004 07:14:51 GMT, flux <support@fluxsoft.com> wrote:

>In article <s8ltq09m5arcc6vfhthdj5gh242rk0j9mc@4ax.com>,
> Malcolm Weir <malc@gelt.org> wrote:
>
>
>That's a very recent developlment. Even gigabit is relatively recent.

1999.

Yes, compared to the development of (say) the microprocessor,
"relatively recent". But compared to the service life of (say) a disk
drive, it was (literally) a lifetime ago.

>
>What other market is there?

Commercial data processing, government, and scientific probably covers
most of the dollars...

>
>Again, this sounds very rare.

Yet it isn't. Gosh. Could it be that you are ignorant of what you
write?

What do you do for a living?

> Where are there disks fast enough to
>saturate this much Ethernet?

EMC, HDS, HP, LSI Logic will happily provide them for you!

Malc.

Malcolm Weir

2004-12-03, 5:45 pm

On Fri, 03 Dec 2004 07:10:02 GMT, flux <support@fluxsoft.com> wrote:

>In article <r1mtq05he18rsmndcftua729m52fruiupa@4ax.com>,
> Malcolm Weir <malc@gelt.org> wrote:
>
>
>How is three years any signficantly less costly than two?

Did you flunk elementary math?

Here's the answer:

In a 6 year period, how often will you have to replace the disks if
you it:

(a) Every two years?
(b) Every three years?

I think you're a troll.

And ignorant!

Malc.

Malcolm Weir

2004-12-03, 5:45 pm

On Fri, 03 Dec 2004 07:07:46 GMT, flux <support@fluxsoft.com> wrote:

>In article <318m7jF385o5qU1@individual.net>,
> "Peter" <peterfoxghost@yahoo.ca> wrote:
>
[vbcol=seagreen]
>No, you are still misunderstanding. I was *intentionally* reading it as
>a literal value.

You could *intentionally* read it as a phone number.

You'd be stupid to do so.

You could *intentionally* read it as the supply voltage, in volts.

You'd be *very* stupid to do so.

Or you could read it as an MTBF, which is what it is, and says it is,
and which is the only "face value" worth considering.

But you appear too stupid to do so.

Malc.

Arno Wagner

2004-12-03, 5:45 pm

In comp.sys.ibm.pc.hardware.storage Anton Rang <rang@visi.com> wrote:
> flux <support@fluxsoft.com> writes:
[vbcol=seagreen]
> *points out the window to the Seagate office down the road*

> I work in storage; I talk with drive engineers (and RAID engineers).

It is also not really surprising, given that SATA is ATA with
better cabeling and a better command-set, but not better drive
hardware or electronics. (I think there is no need to explain why
SCSI is a different quality and performance level than ATA...)

Though sometimes SCSI is not better: I still remember when a lot of
SCSI disk in Suns failed because Quantum had just packed a SCSI
interface on an EIDE disk.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus

flux

2004-12-04, 2:45 am

In article <vns1r01rcuqsnc792jl46is6jalmuoc01s@4ax.com>,
Malcolm Weir <malc@gelt.org> wrote:

> Well, my beliefs are based on experience and direct conversations with
> disk drive manufacturers.
>
> What are yours based on?
>

Ditto.

>
> Figures.
>
> It isn't.

> Drives have a service life which is related to the MTBF, but is
> different from it.
>
> Here's a scenario that is, hopefully, simple enough even for you:
>
> Taking your 1.2Mhour MTBF, that might mean:
>
> Year 1: 1 out of every 150 drives fails. 95% of failed drives get
> returned for replacement. Cost of replacement = 100% cost of new
> drive.
> Year 2: 1 out of every 146 drives fails. 90% of failed drives get
> returned for replacement. Cost of replacement = 90% cost of new
> drive.
> Year 3: 1 out of every 142 drives fails. 85% get returned. Cost of
> replacement = 80% cost of new drive.
> Year 4: 1 out of every 135 drives fails. 75% get returned. Cost of
> replacement = 60% of cost of new drive.
> Year 5: 1 out of every 100 drives fails. 50% get returned. Cost of
> replacement = 40% of cost of new drive.
> Year 6: No one cares. 0% get returned. Cost of replacement n/a.

So my point is logical after all.

>
> Or.... can't find the paperwork/remember that they have a warranty...

Don't mean "and"?

>
> Yes, it is. Welcome to the point. I hope you'll be very happy
> together.

So doesn't that make your argument circular?

flux

2004-12-04, 2:45 am

In article <e3u1r0lliuao7172ilpdeame396cbch0vd@4ax.com>,
Malcolm Weir <malc@gelt.org> wrote:

> On Fri, 03 Dec 2004 07:14:51 GMT, flux <support@fluxsoft.com> wrote:
>
>
> 1999.

Must mean that everyone now has 10G Ethernet at the desktop.

>
> Yet it isn't. Gosh. Could it be that you are ignorant of what you
> write?

Ditto.

flux

2004-12-04, 2:45 am

In article <ccu1r0ddq5hgl6n726vs2po29n9rviqa7a@4ax.com>,
Malcolm Weir <malc@gelt.org> wrote:

>
> Did you flunk elementary math?
>
> Here's the answer:
>
> In a 6 year period, how often will you have to replace the disks if
> you it:
>
> (a) Every two years?
> (b) Every three years?

This is significant?

J. Clarke

2004-12-04, 2:45 am

Arno Wagner wrote:

> In comp.sys.ibm.pc.hardware.storage Anton Rang <rang@visi.com> wrote:
>
>
>
> It is also not really surprising, given that SATA is ATA with
> better cabeling and a better command-set, but not better drive
> hardware or electronics.

Unless it it does have better drive hardware and electronics. There is no
PATA Raptor.

> (I think there is no need to explain why
> SCSI is a different quality and performance level than ATA...)

Because the drive manufacturers decided they wanted it that way. That's the
_only_ reason. Western Digital has decided that they _don't_ want it that
way.

> Though sometimes SCSI is not better: I still remember when a lot of
> SCSI disk in Suns failed because Quantum had just packed a SCSI
> interface on an EIDE disk.

You mean that the disk had a SCSI-to-EIDE bridge on it? Or do you just mean
that Quantum was making bargain-basement SCSI disks using some of the same
components that they used in their consumer line?

You really have to stop confusing the interface with the quality level.
There is no inherent relationship between them. Historically IDE drives
have been built to a lower quality level than SCSI drives. If the drive
manufactures had wanted to position SCSI as the consumer product and IDE as
the enterprise product then you would be complaining about putting IDE
interfaces on cheap SCSI drives instead.
><