www.vampired.net
Write-back cache is much faster.
Basically the OS sends an IO request to the controller, it places the change
in the battery backed up memory and responds complete to the OS.
At this point the transaction is done. Later (ussually seconds) the IO is
written to the disks. This proves to provide very fast response time due to
the quick return to the OS, it also proves very quick as IO is handled in
larger chunks which takes advantage of the higher IO rates as well as
provides very good use of the stripe size to fully utiliize the stripe width
of a volume rather than sending it small IO's and only using few disks.
Write-through simply means the controller will not claim transaction
complete until the disks have stored the information.
This is generally due to the lack of battery backed up ram.
Battery backuped ram gives you the protection of power loss to finish the
transactions on startup. Which is why you can give the quick return to the
OS safely.
There are a few articles on my site on Raid which covers a lot of scsi
technology.
You will find them all under Concepts sections under Articles.
The RAID Awakinging is a good article that covers write-back cache if I
remember correctly.
-----Original Message-----
Sent: Thursday, July 12, 2001 1:42 PM
To: Multiple recipients of list ORACLE-L
Thanks Chris!
I will have to look at your site, what is the URL? Is there
information to check on w/b w/t cache settings? Isn't one of them better
than the other? Also, this is not a RAID system, just a couple of SCSI's
hangin out and being beat on. KK
-----Original Message-----
Spence
Sent: Thursday, July 12, 2001 1:30 PM
To: Multiple recipients of list ORACLE-L
Buzzwords are great.
There are a few good raid papers on my site that cover some of those he
mentioned.
w/t is write through cache
w/b is write back cache
Write back cache is basically battery backed up memory on the raid
controller to provide exceptially high transactional rates.
Stripe size is the size used when creating arrays, it detirmines how the
scsi controller writes out to disks in stripes.
OS block size is the obvious.
Command tagging is when you allow the OS to send multiple scsi commands to
the controller to execute parallel. This in theory reduces the need to
awknowledge each request and execute it.
Disconnect/reconnect support is another feature that allows the disk to
disconnect to from the system when handling a load of requests. This
generally reduces the bus utiliization.
This is a very brief run down of the things mentioned.
HTH,
"Walking on water and developing software from a specification are easy if
both are frozen."
Christopher R. Spence OCP MCSE MCP A+ RAPTOR CNA
Oracle DBA
Phone: (978) 322-5744
Fax: (707) 885-2275
Fuelspot
73 Princeton Street
North, Chelmsford 01863
-----Original Message-----
Sent: Thursday, July 12, 2001 12:21 PM
To: Multiple recipients of list ORACLE-L
Ross,
I love computers and I love tinckering with them to make them run
sweetly, but I don't have a friggen CLUE about what you just wrote!:) Point
me to the mythical paper where all of this vast knowledge and buzzwords came
from and I will dive in:) KK
-----Original Message-----
Sent: Thursday, July 12, 2001 10:56 AM
To: Multiple recipients of list ORACLE-L
also, consider turning OFF command tag queueing....check mobo drivers for
i/o bus-related hw....check w/t vice w/b cache, look at stripe stride vice
os block size.....
Ross
-----Original Message-----
Sent: Wednesday, July 11, 2001 1:41 PM
To: Multiple recipients of list ORACLE-L
Kevin Kostyszyn wrote:
> Hi all,
> I was measuring the i/o performance of my scsi drives and I
> have a
quick
> question that maybe someone could shed some light upon. Currently I
> am using Ultra 2/Wide scsi conrollers, this is supposed to have an I/O
> of 80mb/s. Well, when I perform the test all of the machines seem to
> be operation at halp of the max speed. One operates at about 20mb/s
> read and write and the others are even slower than that. Now on the
> first one, it
is
> the only HD on the controller, on the others there are two disks. Even
> on my Ultra/160 it seems to be maxing out at 40 read and write.
> Am I missing something? Am I reading this the wrong way?
> Help:(
>
> Sincerely,
> Kevin Kostyszyn
> DBA
> Dulcian, Inc
> www.dulcian.com
> [EMAIL PROTECTED]
Kevin,
download SandraSoft's benchmarking tools - download.com is a good place to
start. There is quite a difference between SCSI controller interface speeds
and actual trasfer speeds between the OS and the physical hard drive. The
Interface speed is a theoretical max, and is more important when configuring
several drives on a single controller channel - e.g. RAID 0, 0+1, 5, etc. If
you have 4 drives on a channel configured as a 4 drive RAID 0 volume, the
controller channel SCSI interface speed could be the rate-limiting-factor.
(e.g. 4 drives with an *average* transfer rate of 25 MB/sec = 100 MB/sec >
80 MB/sec).
As there is a cache on the hard drive (2-4 MB is customary) and could be a
cache on the RAID contoller (128 MB - 4 GB?) the channel should be saturated
during memory to memory transfers (after negotiation for the transfer has
taken place) - short bursts which are then slowed by the subsequent access
of the phyiscal media.
Typical sustained read/write speeds are on the order of 30 MB/sec on the
latest and greatest 10,000 RPM drives. The fastest sustained read/write I've
seen is here - is for the 15,000 RPM Seagate Cheetah - close to 50 MB/sec on
the outer tracks
http://www.storagereview.com/articles/200105/20010510ST373405LW_1.html
Interface speed (MB/sec)
SCSI
Ultra Wide UW 40
Ultra2 Wide U2W 80
Ultra160 U160 160
Ultra320 U320 320
IDE
UDMA-33 ATA-4 33
UDMA-66 ATA-5 66
Ultra ATA ATA-6 100
Most likely, seek time will dominate transfer time unless you hike the
operating system IO_size up from 64 KB.
this site looks like fun:
http://www.storagereview.com/cgi-bin/bench_compare.pl
remember - little 'b' is bits, big 'B' is Bytes.
This is extremely important if you happen to look at NAS - using Gigabit
Ethernet for shared storage.
Paul
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Paul Drake
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from). You may also send the HELP
command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Mohan, Ross
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from). You may also send the HELP
command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Kevin Kostyszyn
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from). You may also send the HELP
command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Christopher Spence
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from). You may also send the HELP
command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Kevin Kostyszyn
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the
message BODY, include a line containing: UNSUB ORACLE-L (or the name of
mailing list you want to be removed from). You may also send the HELP
command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Christopher Spence
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
