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.
>
> > 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.
>
> > 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
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
|