IDE RAID

"Tim" wrote in message ...
Ron,

I suggest you read a lot more. Go to the intel site and ferret out the
specs
on the ICH5R (82801ER chip). Read there that it states clearly that it is
Hardware Raid.

Nope, it states NO such thing.

See the ICH5R datasheet (8 MB):
ftp://download.intel.com/design/chip...s/25251601.pdf
5.17.3
The only special RAID functionality regards RAID 0 and not RAID 1.

Goto the Intel site and select advanced search and search on the exact
phrase 'hardware RAID'. Study the results. That will give you a good idea
of what HW RAID is. You will NOT find the ICH5R in that search.

Also note that the manifestation of difference between ICH5
and ICH5R is either a) if it is [perhaps] packed as a ICH5 only and so has
RAID turned off / omitted within the chip, or b) if RAID is turned on or
off
by the bios at boot time - the chip will report itself as 82801EB if RAID
is
off and 82801ER if RAID is on. IE ICH5R = ICH5 with RAID turned on.

Just a subtle difference not related to the difference between SW/FM and
hardware RAID and only related to RAID 0 processing.

The presence of RAID Firmware in the bios is no indication of
a) x86 code running in place of RAID functionality (IE soft raid) or

Quite true in the most general sense however in this case that firmware is
x86 code and it is what handles ALL the RAID functionality until the OS
device driver takes over.

b) that the bios performs the RAID functionality, or

True, until the OS's DD takes over.

c) that all the code is x86 code - it could be a mix of x86 and whatever
code set the RAID controller uses internally for its own private firmware
that it receives on every boot from the bios.

Incredible nonsense.

You will see in the Intel documentation that the bios code provides
specific
supporting funcitonality ie:
a) configuration and management of RAID volumes,
b) boot time access to the RAID drive, and
c) detection of RAID status in the event of failure.

It does all that plus all the other RAID functionality.

The Intel documentation does not say it does anything else. IE it does not
state that it implements soft raid.

Nevertheless it does.

If you also read up about windows drivers you will also learn that bios
functionality is not used within Windows XP when the system is running.

DUH! Read my other post where I talk about that in some detail.

The
purpose of device drivers is to provide windows with software interfaces
to
hardware devices that conform to a specific predefined model so that
Windows
knows how to use the device correctly and automatically.

The 2nd purpose is to locate the code in RAM instead of very slow ROM where
firmware lives.

The responsibility
of the device driver writer is to marry the specific device(s) to the
interface in conformance with the chosen and stated standard (IE you can
take a device that controls SATA drives and implement it as SCSI if you
wish).

Ever write a DD? I'm a DD developer and have written disk device drivers.

You are bound to have noticed that when a SATA RAID controller is
configured as RAID the device is present as a SCSI device.

That's purely a function of the device driver.

This is because
the native SCSI functionality is a more appropriate device model for RAID
and also that the underlying IDE and SATA interfaces are no longer visible
(see the Intel programmers reference for ICH5R for more details, or
Windows
Device Manager). Any functionality provided in the bios (EG boot time
support) is minimal functionality - single threaded reading / writing to
the
device, boot time disc access is not a multithreaded high performance
environment. Bios support is designed for pre-boot execution (EG checking
RAID integrity) or boot: DOS or DOS equivalent access modes (IE boot, and
EG
Nortons Ghost).

Go back and read up in more detail such that you can understand what's
really said in such places.

Having a hardware vendor implement soft raid is unheard of here.

HUH, just clueless!

Virtually all ATA RAID was SW/FM and not HW until 3Ware started doin HW
RAID.

All reviews
of such hardware would be condeming as it would be a poor perfoming,

Pure nonsense. SW/FW RAID performs about as well as HW RAID for RAID 0 and
RAID 1.

deceitful product to claim RAID for a device when the device does not
implement it.

Just NO!

In this country, any vendor of such a product would be legally
liable for such deceit.

Clueless.

If you want soft raid then use the in-built Windows
soft raid functionality on *any* stock IDE or SCSI drive - no special
controller is needed.

Exactly, the difference is that one can't boot from such a RAID 0 array
without that RAID firmware but RAID 1 makes most these cards of little value
IF the OS supports RAID 1.

The OP's original reference was to Intel 865 based motherboards. Making
generalisations about Intel 865 or 875 based hardware when someone
somewhere *may* have done what you claim on totally different hardware is
misleading
at the least. Your references to the Promise hardware indicate your
confusion. On one hand you link to a SATA controller and the other a RAID
controller. What was your point? Which chips contains the on-board
microprocessor? Do you know? "The only difference is the onbaord firmware
chip". What is the make and model number of this chip? I suspect you are
attributing microprocessor functionality to a Flash RAM chip. Onboard or
Onchip controller that needs firmware can be configured to get their
firmware out of the BIOS chip (or the bios supplies it to them somehow).

Your background on these issues is very shallow. Go back to school.

Please, get your facts straight.

- Tim

You can find Intel at www.intel.com
for information on flash memory chips, see www.atmel.com
for information on windows device driver model etc. see
http://www.microsoft.com/whdc/devtools/ddk/default.mspx





"Ron Reaugh" wrote in message
news

"Leythos" wrote in message
...
In article
,
says...
The Promise chip on the mobo is nothing more than a fancy ATA
controller
chip with NO significant RAID functionality on it. All on mobo
Promise
RAID
is firmware/software in x86 code hosted by the host's x86 CPU.

I would be interested in seeing where you get this information from. In
reviewing the Promise RAID 0/1 controller on the motherboard of the
ASUS
PC-DL Deluxe board, I've only seen that the "driver" is a stub


Nope. No clue where you see this as there is full driver support there
in
two different flavors. One RAID and one NOT.

that
allows the OS to recognise the controller (much like the SCSI RAID
Controllers that we use in HP or Compaq servers).

Any OS install requires a F6 driver load just like any other RAID card
that
the OS doesn't already know about.

All my assertions are obvious once one thinks about it. Look at the
specs
for a real HW RAID like a 3Ware and notice the onboard uP.

Look at the SATA card:

http://www.promise.com/product/produ...26&familyId=3#

Look at its nearly identical sibling RAID card:

http://www.promise.com/product/produ...07&familyId=2#

Both use the same Promise SATA controller. The only significant
difference
is the onboard firmware chip, which contains x86 code. One has RAID
functionality and the other doesn't.

Such is well known.

"Leythos" wrote in message
...
In article ,
says...
Then I do 3Ware or SCSI HW RAID 5 with
Fujitsu MAS3735s.

Have you looked at the Promise SX-6000 ATA RAID-0/1/5 controller card.

Don't know. Some of those Promise cards are semi-HW RAID. Where the 'semi'
is mostly relevant to RAID 5 because of a HW XOR engine.

From the intel document "Why_Raid.pdf":

"Industries first desktop RAID controller integrated into the chipset"
"RAID BIOS ROM: Integrated system BIOS, enables pre-OS RAID creation,
mapping, and deletion"

From 25272901.pdf:
"... includes an integrated RAID controller that utilizes the dual Serial
ATA ports for high-performance RAID Level 0.... By integrating the Intel
RAID controller into the I/O controller hub there are no PCI bandwidth
limitations..."

From 25251716.pdf, page 17 (addendum to 25251601.pdf):
"RAID Level 1 is supported in addition to RAID Level 0."

From 25267102.pdf page 28 (somewhat offtopic):
"... does not support surprise removals. ... a device can be powered down by
system software... allowing removal and insertion of a new device". Which is
as I said a while back: No SATA Hot Swap - the implementation is incomplete.

82801 *is* hardware. If the RAID controller is "integrated into" the chip,
then are you saying that Intel is deliberately misleading everyone into
thinking this is not actually a RAID controller at all, that it is some
lesser device that only can do individual IO's to individual volumes?

Now, Ron, how about some evidence - real evidence? You have none so far and
your logic is horribly flawed. You have this horrible habit of saying things
like "No", or "Clueless" and so on. You never substantiate any of your
claims, never even offer any reasoning or documentation for your claims. All
you have offered in all the posts I have read from you are the two
hyperlinks below that point to two different controllers that are
"different". How about it? Show us some documentation that proves beyond all
doubt that your own assertions are correct when they run contrary to Intel's
own documentation? How about proving that the ICH5 firmware is *not* held in
the bios? How about proving that the Windows OS actually isses 2 writes from
the OS to the controller to achieve a write onto 2 physical volumes with
Intel's RAID 1? That is what you are claiming. I don't appreciate being
called clueless, and don't appreciate being run down by someone that claims
to have ddk knowledge when there is nothing evident in their thinking at
all. I would like to know the answers, but at the moment your answers are
useless to everyone as they convey no knowledge or reference to any
knowledge whatsoever. Consequently your posts are more akin to flames and
that is how I have treated them to date.

" Incredible nonsense."? What are microcode updates then? Answer:
proprietary code that is loaded into the Intel CPU at boot time. So why such
nonsense? If the bios can update the microcode at boot time, what is
stopping a bios writer from supplying firmware to an on board manufacturer
designed-in controller such as the ICH5R? Why does this have to be x86 code?
Why does this have to run out of the flash chip (that would be stupid,
memory is cheap remember)? Why does the bios have to contain exclusively x86
code when clearly microcode can be anything that the proprietor of the CPU
decides (it could be x86 code...).

You would do well to read up on the documentation on some of the flash chips
over at atmel. You will find that they have updated quite a bit over the
years and now include support within the chip for 'partitions' so that
different areas of the memory can be erased / updated separately and safely,
can serve different purposes, so that boot blocks can be safe guarded, and
lastly to integrate with the motherboard chips more. IE to serve as the
repository for not just bios but also on board firmware for chips such as
RAID controllers. When you have noted some of these product numbers then go
back and have a look at the difference getweent the two promise cards
previously - the chips may not be atmel or the same as those for your
motherboard bios, but you will find they have similar capabilities and serve
the same purpose. Try a google search on the chips to find out what they
are...

- Tim




"Ron Reaugh" wrote in message
...

"Tim" wrote in message
...
Ron,

I suggest you read a lot more. Go to the intel site and ferret out the
specs
on the ICH5R (82801ER chip). Read there that it states clearly that it is
Hardware Raid.

Nope, it states NO such thing.

See the ICH5R datasheet (8 MB):
ftp://download.intel.com/design/chip...s/25251601.pdf
5.17.3
The only special RAID functionality regards RAID 0 and not RAID 1.

Goto the Intel site and select advanced search and search on the exact
phrase 'hardware RAID'. Study the results. That will give you a good
idea
of what HW RAID is. You will NOT find the ICH5R in that search.

Also note that the manifestation of difference between ICH5
and ICH5R is either a) if it is [perhaps] packed as a ICH5 only and so
has
RAID turned off / omitted within the chip, or b) if RAID is turned on or
off
by the bios at boot time - the chip will report itself as 82801EB if RAID
is
off and 82801ER if RAID is on. IE ICH5R = ICH5 with RAID turned on.

Just a subtle difference not related to the difference between SW/FM and
hardware RAID and only related to RAID 0 processing.

The presence of RAID Firmware in the bios is no indication of
a) x86 code running in place of RAID functionality (IE soft raid) or

Quite true in the most general sense however in this case that firmware is
x86 code and it is what handles ALL the RAID functionality until the OS
device driver takes over.

b) that the bios performs the RAID functionality, or

True, until the OS's DD takes over.

c) that all the code is x86 code - it could be a mix of x86 and whatever
code set the RAID controller uses internally for its own private firmware
that it receives on every boot from the bios.

Incredible nonsense.

You will see in the Intel documentation that the bios code provides
specific
supporting funcitonality ie:
a) configuration and management of RAID volumes,
b) boot time access to the RAID drive, and
c) detection of RAID status in the event of failure.

It does all that plus all the other RAID functionality.

The Intel documentation does not say it does anything else. IE it does
not
state that it implements soft raid.

Nevertheless it does.

If you also read up about windows drivers you will also learn that bios
functionality is not used within Windows XP when the system is running.

DUH! Read my other post where I talk about that in some detail.

The
purpose of device drivers is to provide windows with software interfaces
to
hardware devices that conform to a specific predefined model so that
Windows
knows how to use the device correctly and automatically.

The 2nd purpose is to locate the code in RAM instead of very slow ROM
where
firmware lives.

The responsibility
of the device driver writer is to marry the specific device(s) to the
interface in conformance with the chosen and stated standard (IE you can
take a device that controls SATA drives and implement it as SCSI if you
wish).

Ever write a DD? I'm a DD developer and have written disk device drivers.

You are bound to have noticed that when a SATA RAID controller is
configured as RAID the device is present as a SCSI device.

That's purely a function of the device driver.

This is because
the native SCSI functionality is a more appropriate device model for RAID
and also that the underlying IDE and SATA interfaces are no longer
visible
(see the Intel programmers reference for ICH5R for more details, or
Windows
Device Manager). Any functionality provided in the bios (EG boot time
support) is minimal functionality - single threaded reading / writing to
the
device, boot time disc access is not a multithreaded high performance
environment. Bios support is designed for pre-boot execution (EG checking
RAID integrity) or boot: DOS or DOS equivalent access modes (IE boot, and
EG
Nortons Ghost).

Go back and read up in more detail such that you can understand what's
really said in such places.

Having a hardware vendor implement soft raid is unheard of here.

HUH, just clueless!

Virtually all ATA RAID was SW/FM and not HW until 3Ware started doin HW
RAID.

All reviews
of such hardware would be condeming as it would be a poor perfoming,

Pure nonsense. SW/FW RAID performs about as well as HW RAID for RAID 0
and
RAID 1.

deceitful product to claim RAID for a device when the device does not
implement it.

Just NO!

In this country, any vendor of such a product would be legally
liable for such deceit.

Clueless.

If you want soft raid then use the in-built Windows
soft raid functionality on *any* stock IDE or SCSI drive - no special
controller is needed.

Exactly, the difference is that one can't boot from such a RAID 0 array
without that RAID firmware but RAID 1 makes most these cards of little
value
IF the OS supports RAID 1.

The OP's original reference was to Intel 865 based motherboards. Making
generalisations about Intel 865 or 875 based hardware when someone
somewhere *may* have done what you claim on totally different hardware
is
misleading
at the least. Your references to the Promise hardware indicate your
confusion. On one hand you link to a SATA controller and the other a RAID
controller. What was your point? Which chips contains the on-board
microprocessor? Do you know? "The only difference is the onbaord firmware
chip". What is the make and model number of this chip? I suspect you are
attributing microprocessor functionality to a Flash RAM chip. Onboard or
Onchip controller that needs firmware can be configured to get their
firmware out of the BIOS chip (or the bios supplies it to them somehow).

Your background on these issues is very shallow. Go back to school.

Please, get your facts straight.

- Tim

You can find Intel at www.intel.com
for information on flash memory chips, see www.atmel.com
for information on windows device driver model etc. see
http://www.microsoft.com/whdc/devtools/ddk/default.mspx





"Ron Reaugh" wrote in message
news

"Leythos" wrote in message
...
In article
,
says...
The Promise chip on the mobo is nothing more than a fancy ATA
controller
chip with NO significant RAID functionality on it. All on mobo
Promise
RAID
is firmware/software in x86 code hosted by the host's x86 CPU.

I would be interested in seeing where you get this information from.
In
reviewing the Promise RAID 0/1 controller on the motherboard of the
ASUS
PC-DL Deluxe board, I've only seen that the "driver" is a stub


Nope. No clue where you see this as there is full driver support there
in
two different flavors. One RAID and one NOT.

that
allows the OS to recognise the controller (much like the SCSI RAID
Controllers that we use in HP or Compaq servers).

Any OS install requires a F6 driver load just like any other RAID card
that
the OS doesn't already know about.

All my assertions are obvious once one thinks about it. Look at the
specs
for a real HW RAID like a 3Ware and notice the onboard uP.

Look at the SATA card:

http://www.promise.com/product/produ...26&familyId=3#

Look at its nearly identical sibling RAID card:

http://www.promise.com/product/produ...07&familyId=2#

Both use the same Promise SATA controller. The only significant
difference
is the onboard firmware chip, which contains x86 code. One has RAID
functionality and the other doesn't.

Such is well known.

"Tim" wrote in message ...
From the intel document "Why_Raid.pdf":

"Industries first desktop RAID controller integrated into the chipset"
"RAID BIOS ROM: Integrated system BIOS, enables pre-OS RAID creation,
mapping, and deletion"

From 25272901.pdf:
"... includes an integrated RAID controller that utilizes the dual Serial
ATA ports for high-performance RAID Level 0.... By integrating the Intel
RAID controller into the I/O controller hub there are no PCI bandwidth
limitations..."

From 25251716.pdf, page 17 (addendum to 25251601.pdf):
"RAID Level 1 is supported in addition to RAID Level 0."

From 25267102.pdf page 28 (somewhat offtopic):
"... does not support surprise removals. ... a device can be powered down
by
system software... allowing removal and insertion of a new device". Which
is
as I said a while back: No SATA Hot Swap - the implementation is
incomplete.

82801 *is* hardware. If the RAID controller is "integrated into" the chip,
then are you saying that Intel is deliberately misleading everyone into
thinking this is not actually a RAID controller at all, that it is some
lesser device that only can do individual IO's to individual volumes?

Now, Ron, how about some evidence - real evidence?

Clueless. You simply posted from the spec sheet similar to what I already
cited. You provided NOTHING new beyond what I already showed.

Nothing in that spec sheet says anything about HW RAID. The ICH5R does NOT
do HW RAID. There is no uP and NO buffer. Such are requirements of HW
RAID.


How about proving that the ICH5 firmware is *not* held in
the bios?

Wacko...I was the one that said that the ICH5R firmware WAS in the BIOS.

How about proving that the Windows OS actually isses 2 writes from
the OS to the controller to achieve a write onto 2 physical volumes with
Intel's RAID 1?

It's intuitively obvious. What does the processing if there's a device
error or retry on one drive and not the other? Where does that
functionality live? So when the data must be resent to one drive and not
the other in RAID 1 then what handles that processing. It's all x86 code.
It's all done over the x86 I/O bus. Get a clue. Read up on what real HW
RAID looks like from www.3ware.com

That is what you are claiming. I don't appreciate being
called clueless,

Get use to it when you go out of your depth up against someone who actually
knows something.

and don't appreciate being run down by someone that claims
to have ddk knowledge when there is nothing evident in their thinking at
all. I would like to know the answers, but at the moment your answers are
useless to everyone as they convey no knowledge or reference to any
knowledge whatsoever. Consequently your posts are more akin to flames and
that is how I have treated them to date.

Wacko speak....

Let me see, who would I believe?

Intel?

Someone that calls people wacko with no evidence?

Tough choice Ron.

- Tim

"Ron Reaugh" wrote in message
...

"Tim" wrote in message
...
From the intel document "Why_Raid.pdf":

"Industries first desktop RAID controller integrated into the chipset"
"RAID BIOS ROM: Integrated system BIOS, enables pre-OS RAID creation,
mapping, and deletion"

From 25272901.pdf:
"... includes an integrated RAID controller that utilizes the dual Serial
ATA ports for high-performance RAID Level 0.... By integrating the Intel
RAID controller into the I/O controller hub there are no PCI bandwidth
limitations..."

From 25251716.pdf, page 17 (addendum to 25251601.pdf):
"RAID Level 1 is supported in addition to RAID Level 0."

From 25267102.pdf page 28 (somewhat offtopic):
"... does not support surprise removals. ... a device can be powered down
by
system software... allowing removal and insertion of a new device". Which
is
as I said a while back: No SATA Hot Swap - the implementation is
incomplete.

82801 *is* hardware. If the RAID controller is "integrated into" the
chip,
then are you saying that Intel is deliberately misleading everyone into
thinking this is not actually a RAID controller at all, that it is some
lesser device that only can do individual IO's to individual volumes?

Now, Ron, how about some evidence - real evidence?

Clueless. You simply posted from the spec sheet similar to what I already
cited. You provided NOTHING new beyond what I already showed.

Nothing in that spec sheet says anything about HW RAID. The ICH5R does
NOT
do HW RAID. There is no uP and NO buffer. Such are requirements of HW
RAID.


How about proving that the ICH5 firmware is *not* held in
the bios?

Wacko...I was the one that said that the ICH5R firmware WAS in the BIOS.

How about proving that the Windows OS actually isses 2 writes from
the OS to the controller to achieve a write onto 2 physical volumes with
Intel's RAID 1?

It's intuitively obvious. What does the processing if there's a device
error or retry on one drive and not the other? Where does that
functionality live? So when the data must be resent to one drive and not
the other in RAID 1 then what handles that processing. It's all x86 code.
It's all done over the x86 I/O bus. Get a clue. Read up on what real HW
RAID looks like from www.3ware.com

That is what you are claiming. I don't appreciate being
called clueless,

Get use to it when you go out of your depth up against someone who
actually
knows something.

and don't appreciate being run down by someone that claims
to have ddk knowledge when there is nothing evident in their thinking at
all. I would like to know the answers, but at the moment your answers are
useless to everyone as they convey no knowledge or reference to any
knowledge whatsoever. Consequently your posts are more akin to flames and
that is how I have treated them to date.

Wacko speak....

"Tim" wrote in message ...
Let me see, who would I believe?

Intel?

Intel agrees with me and not you wacko.

Someone that calls people wacko with no evidence?

With substantial evidence that's already been cited. Anyone can read the
whole thread and see for themselves.

Tough choice Ron.

Yep, you're outclassed...give it up.

These ad hominem arguments -- like "wacko" and "clueless" don't strengthen
the case. Above all they don't clarify the disagreement if there is one.


"Ron Reaugh" wrote in message
news

"Tim" wrote in message
...
Let me see, who would I believe?

Intel?

Intel agrees with me and not you wacko.

Someone that calls people wacko with no evidence?

With substantial evidence that's already been cited. Anyone can read the
whole thread and see for themselves.

Tough choice Ron.

Yep, you're outclassed...give it up.

In article ,
Leythos wrote:

In article ,
says...
Nothing in that spec sheet says anything about HW RAID. The ICH5R does NOT
do HW RAID. There is no uP and NO buffer. Such are requirements of HW
RAID.

I may be missing something here, but I don't see anything that states
for something to be a raid controller that it must have a CPU or Cache.
As long as the chipset, using any firmware, handles the communications
with the drive and provides RAID 0/1/5 ability, it's Hardware Based
RAID.

If I use a non-RAID chipset and require the OS to process everything,
then it's soft RAID.

If I'm lucky enough to get cache and a CPU on the controller then I get
even faster RAID.

As I see it, the Promise or Intel RAID chipsets on some motherboards
provide the functionality needed to be considered hardware RAID. Sure,
they don't have their own CPU's, but they do have their own BIOS, do
have their own firmware, do take commands from the OS, and do allow the
creation, building, rebuilding of RAID Arrays before the OS is even
installed on the system.

My understanding of hardware raid is as follows:

For a mirror:

If the OS prepares precisely one block of memory, with data
to be read or written, and the hardware solution takes that
block of memory and reads or writes to two disks, and only
returns "complete" status to the OS when both disks finish,
that is hardware RAID. If the OS has to issue two commands
to the hardware, saying write this to disk 0, then says write
this to disk 1, that is software RAID.

For a stripe:

If the OS prepares precisely one block of memory, and
issues one command to the hardware, and the hardware
alternates writing stripe-sized chunks of data to the
two drives, that is hardware RAID. If the OS chunkifies
the original large memory block, and alternates commands
to the two channels to write a stripe of data to the drives,
that is software RAID.

The difference is in the overhead. With DMA transfer, the
largest overhead of data movement by the processor is
removed. So, these days, it will be harder to tell whether
the solution is hardware or software based underneath. It
will be hard to tell from the remaining level of overhead,
to what extent the hardware hides the details of how the
disk subsystem is wired up, and what it is
(mirror or stripe).

The quality of any solution will be measured in two
parameter - max steady state bandwidth (HDTach) and
percent CPU while doing it. So, experiment and find out.

Whether RAID is hardware or software is based on the
level of abstraction. If the OS/driver, when viewing
the hardware, thinks it is dealing with a single disk,
when in fact the controller handles all the details of
running the RAID, that is a hardware controller. If the
OS is aware of the details underneath, to achieve basic
data transport, then it is a software based controller.

Notice that my definition doesn't cover implementation,
so you don't need to know the private details of how it
is done, to have a definition.

Just my two cents,
Paul

"Leythos" wrote in message
...
In article ,
says...
Nothing in that spec sheet says anything about HW RAID. The ICH5R does
NOT
do HW RAID. There is no uP and NO buffer. Such are requirements of HW
RAID.

I may be missing something here, but I don't see anything that states
for something to be a raid controller that it must have a CPU or Cache.

"RAID controller" is a generic term that could mean most anything. The
issue at hand is the precise and specific meaning of "hardware RAID".

I have already provide the specific criteria required to qualify as
"hardware RAID" earlier in this thread.

As long as the chipset, using any firmware, handles the communications
with the drive and provides RAID 0/1/5 ability, it's Hardware Based
RAID.

That is flat FALSE!

If I use a non-RAID chipset and require the OS to process everything,
then it's soft RAID.

Nope.

If I'm lucky enough to get cache and a CPU on the controller then I get
even faster RAID.

Nope, then you have true hardware RAID.

As I see it, the Promise or Intel RAID chipsets on some motherboards
provide the functionality needed to be considered hardware RAID.

That's flat FALSE.

Sure,
they don't have their own CPU's, but they do have their own BIOS, do
have their own firmware, do take commands from the OS,

Nope, during OS operation ALL the RAID functionality is handled by OS
device drivers and the firmware does nothing. The firmware is only used
during boot an pre OS activity.

and do allow the
creation, building, rebuilding of RAID Arrays before the OS is even
installed on the system.

Exactly...."before".

"formerprof" wrote in message
...
These ad hominem arguments -- like "wacko" and "clueless" don't strengthen
the case. Above all they don't clarify the disagreement if there is one.

There is no case at issue. The definition of "hardware RAID" is well
established in the industry. There are just a few local wackos trying to be
revisionists. Folks engaged in such deserve to be dealt with accordingly.

"Ron Reaugh" wrote in message
news

"Tim" wrote in message
...
Let me see, who would I believe?

Intel?

Intel agrees with me and not you wacko.

Someone that calls people wacko with no evidence?

With substantial evidence that's already been cited. Anyone can read
the
whole thread and see for themselves.

Tough choice Ron.

Yep, you're outclassed...give it up.