508 lines
14 KiB
HTML
508 lines
14 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>The Individual Pieces</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
|
|
REL="HOME"
|
|
TITLE="The Mock Mainframe Mini-HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="Background"
|
|
HREF="x44.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="The Terminals"
|
|
HREF="x187.html"></HEAD
|
|
><BODY
|
|
CLASS="section"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
SUMMARY="Header navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>The Mock Mainframe Mini-HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x44.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="x187.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H1
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN109"
|
|
></A
|
|
>3. The Individual Pieces</H1
|
|
><DIV
|
|
CLASS="section"
|
|
><H2
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN111"
|
|
></A
|
|
>3.1. The Mock Mainframe</H2
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN113"
|
|
></A
|
|
>3.1.1. The Hardware</H3
|
|
><P
|
|
> <STRONG
|
|
>Examining your needs.</STRONG
|
|
> If the load that is going to be placed on the mock
|
|
mainframe is more or less constant and won't change too much over time, you
|
|
are in the wonderful position of being able to tailor your hardware to your
|
|
needs. This probably will let you get away with second-hand hardware, which
|
|
leaves you with more money for, say, a new surround sound system (or more
|
|
realistically, a new dish washer).
|
|
</P
|
|
><P
|
|
> The simple way to find out just what you need is to throw together a
|
|
machine, just about <EM
|
|
>any</EM
|
|
> machine, and then see how it performs under the
|
|
load it will actually be asked to bear. Then experiment a bit: Will the
|
|
computer start to swap if you take out half of the RAM, will it speed up if
|
|
you put in double the amount? See if you can get away with a slower
|
|
processor or a smaller hard disk. If you can, get feedback from your users.
|
|
</P
|
|
><P
|
|
> These trial runs can take time and may seem like a lot of work. The idea
|
|
here is to fit the mock mainframe's hardware as exactly as possible to the
|
|
task at hand so you can use the rest of the hardware for other stuff. Also,
|
|
these trial runs can have surprising results. Most people have little
|
|
experience in building a system for more than one user, and tend to
|
|
overestimate the processor strength required while underestimating the
|
|
amount of memory they need.
|
|
</P
|
|
><P
|
|
> For example, for our setup at home in 2003 — two people running
|
|
SuSE 8.2 and KDE 3.1 with a regular load of email clients, multiple browser
|
|
windows, chatting and music playback — an AMD Duron 1.0 GHz processor
|
|
turned out to be overkill. We ended up with a secondhand SMP mainboard with
|
|
two used Intel Pentium II Xeon 450 MHz CPUs (yes, Pentium "two"). Further
|
|
experiments showed that 512 MByte RAM was slightly too much RAM: 384 MByte
|
|
is fine, if you can live with the system going into swap once in a blue
|
|
moon.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Multiple vs. single processors</STRONG
|
|
> With more and more people working on one
|
|
computer at the same time, you'll start having moments when a single
|
|
processor machine seems to stall. Also, if somebody's process goes berserk
|
|
and starts hogging the CPU, it can freeze the whole system. This is bad.
|
|
</P
|
|
><P
|
|
> Decades of hardware marketing have produced computer users who reflexively
|
|
go out and buy a faster processor when things slow down. But even the
|
|
fastest CPU can't do more than one thing at once (we're ignoring tricks
|
|
like hyperthreading here), it is just somewhat better at faking it. To really
|
|
do two things at the same time, you need more than one processor. Such
|
|
systems are usually referred to as "SMP"-computers, from <EM
|
|
>symmetrical
|
|
nultiprocessing</EM
|
|
>. You can get them with eight processors or more (Intel
|
|
Pentium II Xeon, AMD Opteron, Intel Xeon) but in our price range, two CPU
|
|
(<EM
|
|
>dual-processor</EM
|
|
>) systems are the most common.
|
|
</P
|
|
><P
|
|
> More than one processor will go a long way towards keeping the system
|
|
responsive even when there are lots of processes running. What it will
|
|
<EM
|
|
>not</EM
|
|
> do is make a single process run twice as fast as on a system with a
|
|
single processor of the same speed. One way to visualize this is to imagine
|
|
you are doing your laundry: Two washing machines will get the whole job
|
|
done in about half the time, but that does not mean that they now each spin
|
|
twice as fast; each load still takes just as long as before. Things are
|
|
actually more complicated, but this is a good rule of thumb.
|
|
</P
|
|
><P
|
|
> Although processor speed might be important for gamers on the bleeding edge
|
|
or people who want to simulate nuclear explosions on their desktop machine,
|
|
the current clock speeds are simply perverse for normal use. You can
|
|
usually get away with far slower processors than the market is trying to
|
|
force down your throat, especially if you have more than one CPU. This is a
|
|
good thing because SMP-mainboards are more expensive than normal,
|
|
single-processor boards, and then you still have to buy that second
|
|
processor. Keep in mind that more recent (AMD Opteron / Intel Xeon) SMP
|
|
systems can have expensive needs such as a special power supply and extra
|
|
large cases.
|
|
</P
|
|
><P
|
|
> A multi-processor mainboard is not a must for a mock mainframe. But if you
|
|
find your system groaning under multiple users, adding processors might
|
|
give you a better deal than adding MHz.
|
|
</P
|
|
><P
|
|
> (At the time of writing, there was also the problem of latency in the Linux
|
|
kernel. In the 2.4.x series, the kernel is not pre-emptable, so
|
|
occasionally a one-processor system will stall while something is happening
|
|
in the bowels of the operating system. The 2.6.x kernels are supposed to be
|
|
far more responsive, which would be the end of that problem and of this
|
|
paragraph,too).
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Storage: SCSI vs. IDE, RAID</STRONG
|
|
>. You might want to take a look at using SCSI
|
|
instead of IDE for hard disks and other drives. One advantage of SCSI is
|
|
that you can connect more drives to one computer than the four you are
|
|
usually limited to with IDE. SCSI drives are also better at moving data
|
|
back and forth amongst themselves without bothering the processor. They are,
|
|
however, more expensive and can be louder. On smaller systems with few
|
|
users and low loads, you should be able to use IDE drives with no problem.
|
|
</P
|
|
><P
|
|
> If you are going to build a system where it is important you don't loose
|
|
your data even between those regular backups you perform every night right
|
|
after you floss your teeth, you might want to consider a RAID (<EM
|
|
>Redundant
|
|
Array of Inexpensive Disks</EM
|
|
>) setup. Very roughly speaking, a RAID setup
|
|
duplicates the data on more than one hard disk, so that if one drive
|
|
crashes, the others still have copies.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Sane graphics.</STRONG
|
|
> Most graphics cards cater to the game freak who has an
|
|
unlimited hunger for speed, speed, and more speed and the pocket depth to
|
|
match. An AGP graphics card with 128 MByte of RAM and dazzling 3D functions
|
|
is not necessarily a bad thing in a mock mainframe, but be sure that you
|
|
actually need it. A good used PCI card will usually do just fine for email
|
|
and surfing.
|
|
</P
|
|
><P
|
|
> <STRONG
|
|
>Heat and Lightning.</STRONG
|
|
> Beyond the normal hardware considerations mentioned
|
|
here, give some thought to the parts that protect your machine from threats
|
|
such as power surges or brown outs, or makes sure that everything stays
|
|
cool, or shields your drive bays from inquisitive little children with
|
|
popsicle sticks. A good modern mainboard has temperature alarms and all
|
|
sorts of other features to help you monitor your system's heath.
|
|
</P
|
|
><P
|
|
> In summary:
|
|
</P
|
|
><P
|
|
></P
|
|
><OL
|
|
TYPE="1"
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Think RAM before processor speed.</EM
|
|
> With more than one user, you'll be
|
|
using more memory and less CPU time than you expect.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Two slower processors can be better than one fast one.</EM
|
|
> A faster
|
|
processor can switch between more than one task faster than a slow one,
|
|
but two processors don't have to switch at all. This means you can use
|
|
older hardware, which will almost always be less expensive even though
|
|
you will need more of it.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
> <EM
|
|
>Consider SCSI and RAID.</EM
|
|
> SCSI instead of IDE gives you more drives on
|
|
one machine, and they are able to play amongst themselves without
|
|
processor supervision. However, SCSI drives are more expensive and make
|
|
more noise. RAID helps protect your data from hard disk failure. Both
|
|
are for more ambitious setups.
|
|
</P
|
|
></LI
|
|
></OL
|
|
><P
|
|
> When buying hardware for a mock mainframe, online auctioneers are your
|
|
friends. Whereas your local computer store will try to sell you the newest
|
|
fad, there is no shortage of previous-generation hardware at affordable
|
|
prices online.
|
|
</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="section"
|
|
><H3
|
|
CLASS="section"
|
|
><A
|
|
NAME="AEN151"
|
|
></A
|
|
>3.1.2. The Software</H3
|
|
><P
|
|
> <STRONG
|
|
>Some background on X.</STRONG
|
|
> The X Window System (<EM
|
|
>X Windows</EM
|
|
> or just <EM
|
|
>X</EM
|
|
> for
|
|
short) is the graphics layer that most Linux systems use. Almost all
|
|
current window managers — KDE, Gnome, Blackbox — sit on top of X, and
|
|
almost all variants of Unix use X.
|
|
</P
|
|
><P
|
|
> X Windows has one important aspect that we make extended use of with the
|
|
mock mainframe: It is <EM
|
|
>network transparent</EM
|
|
>. The software responsible for
|
|
controlling the input/output devices — screen(s), keyboard, and mouse —
|
|
can be on a different computer than the programs you are actually running.
|
|
With X, it is possible to sit in Beijing, China, with a 486DX and run your
|
|
programs on a supercomputer in Langley, Virginia.
|
|
</P
|
|
><P
|
|
> This has a whole number of advantages. Graphics are hard work for a
|
|
computer; having them processed on a different machine than the program
|
|
they belong to takes a big load off of the central computer. They are not
|
|
so hard, however, that they can't be handled by an older processor. In the
|
|
distant past of computer technology, there were special machines called <EM
|
|
>X
|
|
Terminals</EM
|
|
> that did nothing but display graphics. Today, a spare computer
|
|
with an Intel PentiumPro or an AMD K6 with 300 MHz is enough. This lets
|
|
you have one big, fat machine running the actual programs and a whole host
|
|
of cheap, small machines doing all the graphics. Which is exactly what we
|
|
are looking for.
|
|
</P
|
|
><P
|
|
> X Windows does have some drawbacks. It gobbles up a lot of bandwidth, so
|
|
you will want a fast network. Also, some of the terminology is strange. The
|
|
computer (or rather the software) that controls screen, mouse, and keyboard
|
|
is called the "X server", because it "serves" the actual program, which in
|
|
turn is called the "X client". In this text, we'll stick to "host" and
|
|
"terminals" to avoid confusion.
|
|
</P
|
|
><P
|
|
> There are all kinds of good Linux HOWTOs about X Windows, so again we'll
|
|
just go through the basic steps and let you consult the special texts. I'm
|
|
assuming that you already have X set up on the mock mainframe; your
|
|
distribution should handle that part for you.
|
|
</P
|
|
><P
|
|
> First, we have to start the program that handles remote X logins. This is
|
|
<TT
|
|
CLASS="literal"
|
|
>xdm</TT
|
|
> (<EM
|
|
>X Display Manager</EM
|
|
>). Depending on your system and taste, you might
|
|
want to use the KDE version <EM
|
|
>kdm</EM
|
|
> or Gnome version <TT
|
|
CLASS="literal"
|
|
>gdm</TT
|
|
> instead; both have
|
|
nicer graphics and more features. Check the <EM
|
|
>XDMCP Mini-HOWTO</EM
|
|
> by Thomas
|
|
Chao for more details. Normally, you'll want <TT
|
|
CLASS="literal"
|
|
>xdm</TT
|
|
> (or whatever) to start
|
|
up in the run level that you ususally use for graphics (for example, run
|
|
level 5 for SuSE 8.2).
|
|
</P
|
|
><P
|
|
> Even when <TT
|
|
CLASS="literal"
|
|
>xdm</TT
|
|
> is running, the mock mainframe should not let you connect
|
|
from the outside, which is good security. You distribution might let you
|
|
change this with a simple entry in one of its configuration files (for
|
|
example, SuSE 8.2 uses <TT
|
|
CLASS="literal"
|
|
>/etc/sysconfig/displaymanager</TT
|
|
>). If you have to do
|
|
it the hard way, you will want to change <TT
|
|
CLASS="literal"
|
|
>/etc/X11/xdm/xdm-config</TT
|
|
> and
|
|
<TT
|
|
CLASS="literal"
|
|
>opt/kde3/share/config/kdm/kdmrc</TT
|
|
> if you are using <TT
|
|
CLASS="literal"
|
|
>kdm</TT
|
|
>.
|
|
</P
|
|
><P
|
|
> After all of this is done, you are ready to test the link. Get a computer
|
|
you know has a functioning X system, boot it in console mode — <EM
|
|
>not</EM
|
|
> in
|
|
graphics mode (runlevel 3 instead of 5 on SuSE systems, use <TT
|
|
CLASS="literal"
|
|
>init 3</TT
|
|
> as
|
|
root from a shell). Log in and type
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> /usr/X11/bin/X -terminate -query <host>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> where "<host>" is the name or IP-address of the mock mainframe. You should
|
|
get the same X login prompt as if were sitting at the host machine.
|
|
</P
|
|
><P
|
|
> Even if you have booted into graphical mode, you can try the following to force the X server to start a second display:
|
|
</P
|
|
><TABLE
|
|
BORDER="0"
|
|
BGCOLOR="#E0E0E0"
|
|
WIDTH="100%"
|
|
><TR
|
|
><TD
|
|
><FONT
|
|
COLOR="#000000"
|
|
><PRE
|
|
CLASS="screen"
|
|
> /usr/X11/bin/X :1 -terminate -query <host>
|
|
</PRE
|
|
></FONT
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><P
|
|
> This can be done from within a terminal program such as <TT
|
|
CLASS="literal"
|
|
>xterm</TT
|
|
> on the running display. Note that by default, the first display is :0.
|
|
</P
|
|
><P
|
|
> The rest of the text is written under the assumption that you will be using some standard distribution such as SuSE or RedHat or Gentoo for the mock mainframe. However, it should also be little trouble to adapt the Knoppix terminal server package (see <A
|
|
HREF="http://www.knoppix.net"
|
|
TARGET="_top"
|
|
>http://www.knoppix.net Knoppix</A
|
|
>) so that it boots right off a ramdisk.
|
|
</P
|
|
></DIV
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
SUMMARY="Footer navigation table"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x44.html"
|
|
ACCESSKEY="P"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
ACCESSKEY="H"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="x187.html"
|
|
ACCESSKEY="N"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>Background</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>The Terminals</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |