On Wed, 20 Jan 1999, Alvaro A. Novo wrote:
> Hi,
>
> Before I attempt to install Linux (RedHat 5.1) on a new dual processor
> machine, I would like to hear from you about any possible incompatibilities
> (particularly hardware). I have been using Linux in a "simple" PC, but this
> is completely new to me. These are the details:
>
> o Dell PowerEdge 6300, 400 MHz/512K Cache
> o Intel Pentium II Xeon (2 of them, dual processor!)
> o 512MB RAM (4x128MB) EDO DIMMs
> o 32 SCSI CD ROM
> o 9GB LVD SCSI Smart Hard Drive, 7200 RPM
> o 12/24GB DDS-3 DAT internal Tape Back Up
> o Intel Pro 100 Plus Ethernet Network Card
> o AccelStar 2d/3d Graphics Accelerator w/ 8mb SGRAM
> o DellPlus Intel Ultrascan 1600HS (19.8")
I don't have a 6300, but I have a bunch of 2300's. Your configuration
should work fine, except that I had to search around pretty hard to find
an X driver for the AccelStar. At the time (six months ago) SuSE had
the only driver; by now it may be incorporated into XF86 proper. At
least you can be reasonably confident that it is possible to make it
work either way.
If you use the latest 2.0.x kernel (36 or 37 or whatever) it should have
aic7xxx drivers that work with your onboard SCSI controllers. The
eepro100 drivers ditto. I don't have the DDS-3 DAT in a 6300, but I do
have one on a AIC2940 and it works excellently well. I have had no
problems with Dell's SCSI drives, although their WD drives don't (or
didn't when we got ours) support tag queuing and hence are probably not
the best performers conceivable.
My only two criticisms of your configuration would be: why EDO instead
of SDRAM and why Xeons? Xeons are still pretty pricey, run no faster
than 400 MHz, and IMHO are probably not worth the price premium to
"most" users. So I hope that either you are pretty sure that you are in
the category where their extra large/fast cache will make a performance
difference worth the cost difference (or at least will make a
PERCEIVABLE performance difference of some kind) or that you have a deep
budget and much don't care what the system costs.
At constant cost I'd be inclined to reconfigure with 450 MHz ordinary
PII's (to my experience for most folks most of the time, raw clock is
overwhelmingly the dominant system performance determinant) and put the
savings toward getting a faster disk, more disk, PC-100 SDRAM, a CD
burner instead of a RO CD drive, a zip drive for making smallish dumps,
a top grade sound system so you can play Bach or the Dead while you work
(as your spirit dictates), a really nice printer, whatever -- anything
in this sort of peripheral/enhancement category that you might find
useful. At least then you'd be able to see the value your money buys;
with the Xeon vs Regular tradeoff, I predict that you'd never notice it
either way UNLESS your application is one of the relatively few memory
bound applications with the right stride to be significantly improved by
the faster/bigger cache AND the time saved (still likely to be pretty
small) is worth it. Indeed, if your application IS in this category,
you should worry about having a dual CPU system at all -- having two
CPUs is not much help if the I/O subsystem is saturated or nearly so by
just one.
> I would appreciate any help, including Linux packages suggestions (RedHat,
> SuSE, Caldera). This machine will be a multi-user one, networked through
> University of Illinois services.
This would get into religious territory and I'm ecumenical. I'm sure
that there are a few wild-eyed, long haired prophets in the crowd who
will speak out for each one. The only places where I can see that
you'll have to do some work regardless are finding the right X driver
(see above) in the even that it still isn't mainstream and building an
SMP kernel (not particularly difficult, but you will probably have to
replace the UP kernel that most distributions assume that you need so).
Some packages care more than others about just how you build a kernel
and an associated module set.
One last thing that you will want to consider will be going over to
2.2.x from 2.0.x. If the system is to be a heavily multiuser server
(e.g. a login/mail/NFS server) there might well be more benefit from
doing this than from anything you do at the system configuration level
as the 2.2.x kernel is supposedly significantly more efficient than
2.0.x at a very mixed multitasking load, especially when simultaneous
access to different devices (e.g. the network and the disk) are likely
to be frequently requested. 2.2.x will actually parallelize these,
handling the network with one CPU and the disk with the other, for
example, while 2.0.x will handle first one, then the other, on a single
CPU. With enough work to do, the other CPU won't be idle in the
meantime, but 2.0.x has only a single kernel lock and so there are
definitely event sequences that will be effectively blocked and hence
run noticeably more slowly. At this time, I don't know if any
distributions come with 2.2.x (or even 2.1.x) preloaded and ready to
install or configure/compile, so you may want to ask around and find out
which distributions are relatively "friendly" to the 2.2 kernel upgrade.
I'm sort of curious myself. Slackware obviously doesn't care at all
because once it is installed you're on your own and if you want to put
in a 2.[1,2].x kernel that's fine with it (been there, done that, worked
fine). Red Hat appears pretty picky about just how you build kernels
and I've only been playing with it for a month or so and have had no
need to do a new build. I should probably try the RH 2.2 upgrade
myself just on general principles.
Debian was just recommended to me yesterday as being very mature and
well worth trying by a wild eyed individual wearing a long robe and
carrying a staff. How easy is it to go 2.2 with Debian? SuSE?
Caldera? Are any besides Slackware in the "make the kernel you like,
pop it in /vmlinuz, run lilo, reboot" category?
> ps. If you feel that I should e-mail an alternative mailing list, please
> let me know.
No, this is the place. But see the lines below, in case you haven't yet
perused the linux SMP FAQ! Some (but not all) of your questions or
concerns are probably addressed there in detail. Ones that aren't
probably should be.
> -
> Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
> To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
HTH,
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
