mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Tom Sightler" <ttsig@tuxyturvy.com>
To: <mjacob@feral.com>, <Matt_Domsch@dell.com>
Cc: <linux-kernel@vger.kernel.org>
Subject: Re: No SCSI Ultra 160 with Adaptec Controller
Date: Wed, 24 Jan 2001 15:07:50 -0500	[thread overview]
Message-ID: <004901c08641$54d86d40$1a040a0a@zeusinc.com> (raw)
In-Reply-To: <Pine.BSF.4.21.0101232041310.5712-100000@beppo.feral.com>

> Actually, aren't a number of newer drives getting upwards of 30MB/s?
>

Well, at 80MB/sec these drives are able to come in at an average of about
34MB/s across the board.

> > Therefore, you only exceed the 80MB/sec bus speed if you
> > have more than 4 disks all doing maximum I/O at the same time.  Since
the
> > PowerApp.web 100 has at most 2 disks internally, you really shouldn't
see
> > any significant performance difference.

I wouldn't dare argue that I'd get some huge performance boost, but I am
running software raid1 on multiple spindles (we have some drives attached
externally) so it should help some.
Also, this unit is doing heavy read/write of small files and the lower
latency, and
burstable transfers do help some.  I temporarily disabled that code and the
increase in IO's per second is measurable, though not earth shattering, but
I
was afraid to leave it that way because fast corrupted data is worth much
less
that only slightly slower good data.

It was really just an issue of if the code still needed to be there.
Workarounds that are put in as temporary have a tendency to never get
revisited
until someone brings them up, and on top of that they make Linux look sloppy
to
me (the same drives work correctly at Ultra160 under that other OS, or at
least appear to).  I know it
won't make a huge difference to me, but if some user has a 12 disk RAID
array
full of Quantum disks it will make a big difference to them.

Later,
Tom



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  parent reply	other threads:[~2001-01-24 20:09 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-24  4:34 Matt_Domsch
2001-01-24  4:41 ` Matthew Jacob
2001-01-24 15:37   ` John Jasen
2001-01-24 17:13     ` Matthew Jacob
2001-01-24 20:07   ` Tom Sightler [this message]
2001-01-24 20:27     ` Matt Domsch
2001-01-24  6:43 ` Tim Sullivan
2001-01-24 14:57   ` Martin Josefsson
2001-01-24 14:43 ` I Lee Hetherington
2001-01-24 15:30   ` Matt Domsch
  -- strict thread matches above, loose matches on Subject: below --
2001-01-24 20:13 Nathan Black
     [not found] <CDF99E351003D311A8B0009027457F1403BF9C0F@ausxmrr501.us.dell.com>
2001-01-24 15:20 ` Tim Sullivan
2001-01-24  2:27 Tom Sightler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='004901c08641$54d86d40$1a040a0a@zeusinc.com' \
    --to=ttsig@tuxyturvy.com \
    --cc=Matt_Domsch@dell.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjacob@feral.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®