rawio
[Top] [All Lists]

Re: Ping

To: bapper@xxxxxxxxxxxxxxx (Brian Pomerantz)
Subject: Re: Ping
From: slurn@xxxxxxxxxxxxxxxxxxxx (Scott Lurndal)
Date: Fri, 24 Mar 2000 15:27:57 -0800 (PST)
Cc: rawio@xxxxxxxxxxx
In-reply-to: <20000324145934.A19118@xxxxxxxxxxxxxxxxxxxxx> from "Brian Pomerantz" at Mar 24, 2000 02:59:34 PM
Sender: owner-rawio@xxxxxxxxxxx
> 
> On Fri, Mar 24, 2000 at 02:44:25PM -0800, Scott Lurndal wrote:
> > > 
> > > I'm a Linux developer at LLNL and am currently working on squeezing as
> > > much performance out of a couple of RAID systems on Alpha Linux as I
> > > possibly can.  Right now I'm working on getting some QLogic QLA2200
> > > going as well as a rack of 8 Ciprico Rimfire 7010's going.  I guess
> > 
> > There is a driver from qlogic (qla2100.c) in the SGI propack which
> > performs quite a bit better (and more reliably) than the qlogicfc
> > driver in the standard linux trees.   (propack is on http://oss.sgi.com)
> > 
> 
> Will this driver work under Alpha Linux?  I guess I'll download it and
> give it a try.

I don't believe that there are any intelisms in the driver, but 
I've not tried it on alpha myself.  It came directly from qlogic
and is based upon their master source tree (which supports most
proprietary unices) so I suspect it will work fine.

> 
> > 
> > > the performance numbers under Irix are around 50MB/s writes per
> > > controller and 90MB/s reads.  I'm hoping to attain this performance or
> > > better with the rawio patches.  So my question is, is this stuff still
> > 
> > To a certain extent, the performance also depends on the system
> > chipset - some intel motherboards for example won't do more than
> > 70 or 80 mbytes/sec on the pci bus. 
> 
> On our ES40s (quad Alpha cpus), we are seeing about 212MB/s maximum
> throughput on the PCI bus so we shouldn't have a problem there.

On a single bus?  Ah, alpha - 64 bit PCI bus, right?  Is it 33mhz or
66 mhz?

> 
> > 
> > > being worked on and if so, are there plans on working it into the
> > > kernel?  I think I saw that Steven Tweedie's work is already in the
> > > 2.3.xx tree, what sort of difference in performance can I expect
> > > between the SGI changes and the work that Steven Tweedie has done?
> > 
> > There are two key differences in the sgi raw I/O over what
> > is in 2.3:
> > 
> >     1) Device naming (/dev/raw pseudo devices in SCT vs. 
> >                       /dev/rsd* character devices in SGI patch)
> > 
> >     2) I/O size (SCT patch breaks all raw I/O up into 1 or 4k
> >                  chunks.   SGI patch will issue full sized 
> >                  I/O's (up to 1Mb per I/O)).
> > 
> > We'll have a 2.3.99pre patch next week sometime.
> > 
> 
> Do you know what the chances of this stuff making its way into the
> main Linux kernel are?  It sounds to me, without having used either of
> these patches yet, that the approach SGI is taking is a little more
> robust and easier for developers to utilize.  I would like to minimize

I tend to agree with the above characterization - particularly that
the interface via the character device is exactly the same on 
all flavors of unix.   The linux /dev/raw stuff is an anomoly 
and limits one to 256 raw partitions - a significant limitation
on large systems.

Insofar as acceptance goes, I'm trying to craft the patch in
such a way that it won't be objectionable to the community - 
but no guarantees.  We are willing to work with the community
to ensure acceptance eventually.   It is likely that the XFS
work will make use of the scsi raw stuff for performance reasons, 
so we may push it through that vehicle - xfs should be released
shortly (perhaps next month).

scott

> the number of dependencies we have on foreign patches as I don't
> really want to have to maintain things that aren't part of the regular
> kernel if the original developers stop maintenance.  As it is we have
> quite a few changes we've had to make to the kernel for our cluster
> work.  Hopefully we'll have these changes made public soon and can
> work on getting them accepted into the main kernel tree.
> 
> 
> BAPper
> 
> 
> BAPper
> 


<Prev in Thread] Current Thread [Next in Thread>