From: phan...@well.sf.ca.us (Pete Hanson)
Subject: SUMMARY: Linux and Large Systems
Organization: The WELL
Date: Wed, 14 Oct 1992 18:49:57 GMT
Here is a summary of the responses to the questions I asked last week
about using Linux on a system meant to support up to 50-60 simultaneous
users. Thanks to everybody who responded -- now to convince my
associate that he won't be able to get the performance he needs out of
this type of setup.
An associate of mine is attempting to put together a 486 system that
will be used to support a fairly large community of medical
practitioners. He is hoping to use Linux as the base operating system,
and has asked me to look into some technical matters for him. Some of
these questions may or may not be appropriate for this newsgroup, so
pointers to more approp- riate newsgroups will be appreciated.
Anyway, he would like to have a system that supports in the
neighborhood of 50-60 users per machine, most connecting to the host
via dialup ports. The first obvious question is how many simultaneous
users is Linux capable of supporting? Does anyone know of any
multi-serial port cards capable of handling that many connections at
the same time?
He is also looking for this enterprise to be set up as an almost
exclusively telecom-run type of deal, including programmers, support
personnel, *and* the system administrator checking in via telecom.
(Yes, he is aware of the potential security problems here.) It's this
last item that is of concern. I've seen a number of hardware/software
packages in the IBM mainframe (Yuch!) world that allow the system
administrators/operators run the system console (including booting)
entirely from a remote console. Since I'm fairly new to the UNIX
world, I haven't seen anything like this yet, though I imagine
something of the sort must exist to support networked systems run from
a central location. Is anybody aware of such a package that can be
used to run a 486-based UNIX system (particularly under Linux)? This
would have to provide access to the system console in both single and
Thanks in advance for any information or pointers anyone has.
From: Cameron Spitzer 764-6339 <camer...@nad.3com.com>
This kind of thing is often done with a modem server hooked to the compute
server by ethernet. The alternative, a PC stuffed with multiport serial
cards hooked to a rack of "external" modems is a big mess.
Even a couple of cheap terminal servers hooked to a rack of modems might
be a better setup than the multiport serial cards.
You'd have to look in the trade jounals for modem servers. The only brands
I know are Gandalf and Telebit, but I know it's a competitive market.
From: Steven Bairstow <bairs...@vivaldi.psu.edu>
I know there are products regularly advertised in UnixWorld magazine that
would be able to give this many ports. There are two types, one that goes
on a SCSI bus and one that has its own host card. I beleive that the vendors
(I can't kind the names now, ask me if you really want them.) would supply
the basic drivers for their product and you would probably have to recompile
the kernel. In my opinion, a better idea would be a network (EtherNet is
under Linux) of several 486 machines (50 simultaneous users is likely to
slow anything below a mainframe down.) and use the kind of dial-up terminal
server you would see a university using.
I won't say it's impossible, but what you want to do is marginal, at
least if you insist on a single system. I use Linux at home, but for
multiuser purposes my experiences are only Suns. A 486 is probably
about equivalent to an IPC. I wouldn't try to put 50-60 users on an
IPC. The 486 is going to have an additional problem: ISA systems
aren't going to have the I/O throughput to handle large-scale
multiuser use. Your only hope would be an EISA system whose disk
controller is sufficiently compatible with ISA ones for Linux to
handle, but that used full 32-bit transfers. Or maybe a LocalBus
system with similar characteristics. But I'm sceptical. PC's just
weren't built for large-scale multiuser use. Is there some way you
can scale down the number of users per system? (Unfortunately,
networking on Linux is still in the early stages, so you can't share
disks via NFS.)
I'd like to suggest that for this purpose a Sun, HP, etc, might be a
better choice. We've had 60 users on a Sparcstation 2, though not
doing anything significant. (This is our Campuswide Information
System, which is a very low-overhead menu system.) For this system,
we have two fast SCSI disks and 64MB of memory. You could probably
put together a 486-based equivalent (e.g. the Compaq [?] SystemPro),
but I don't think Linux would support it. (Among other things, it's
got multiple processors.) And I think it might actually be more
expensive than the Sun.
From: coryw...@is.rice.edu (Cory Richard West)
If you wanted 50-60 _simultaneous_ users, then Linux is definitely
not the way to go. For that sort of computing, you should look into a
Sun 4/490 and a Cisco Terminal Server. As far as limitation on Linux,
if you have a _fast_ hard drive and a reasonable ammount of RAM (32-64 megs)
it should be able to support 4-8 simulataneous connections. Allocate approx.
8 megs per user and hope to god they don't need to use the AT bus all that
much (access the disk, swap, etc.)
About serial cards. I think that you can put _at the most_ 4 four-port
cards, getting you 16 simultaneous connections. Of course, I've never known
anyone to try this, so I would suggest that you have a programming manual and/or
a programmer handy.
Remember that Linux is still quite young. It's a great OS and I love it,
but I don't think it's really cut out for a production computing shop. Since it's
also trapped on an AT bus, it's just no performance wonder for lot's of multiple
users. If you only want a person or two using the system simulatneously and
don't mind having to do a LOT of sysadministartion to keep up with the changing OS,
it will probably be fine. If you need more simulatneous users and more reliability,
you should look at a production machine, like a Sun or an HP.
From: Alan Cox <iiitac%pyr.swan.ac...@ib.rl.ac.uk>
What you get out of linux will depend on your machine speed are more
importantly on ram size and disk usage. Its hard to be sure what you
will need. I've seen PC based systems support 20 users at a struggle.
At this point the disk and the isa bus become a nightmare. To get
this kind of system performance you are looking at a 16Mb 386DX or 486
with 16550A uarts on all the serial ports (you can get linux to handle
about 12 ports if you use the right cards). For a disk you probably
want a 9ms scsi disk with an adaptec 1542 controller or better.
Some commercial unices support eisa, which will give you a better
performance, but linux doesn't do this.
As to booting over a serial line. Its already built into linux.
The system boots over tty1 which defaults to 2400 baud if its a serial
line. Thus you just move /dev/tty1 and make /dev/tty1 a link to onme
of the serial lines and off you go. I ran linux for about 2 months without
a console display of any kind.
For security you can get hold of packages like npasswd which forces good
password choices, crack which finds bad passwords and mails the offender
rude messages, and cops which hunts for setup errors.
To be honest if you want more than about 10 users per machine I'd say
look elsewhere from the PC market, or at least go ethernet where the
load on a PC is less.
From: asht...@yoyo.cc.monash.edu.au (John Newnham)
The best advice I have at present is that to go past about 16 users, you
have to use a dedicated box - probably a TCP/IP terminal server.
From: david...@ariel.crd.ge.com (william E Davidsen)
I don't believe Linux will do this. I haven't looked at the sources in
the last month, but the old sources included a limit of 64 as the
highest process number, and I haven't seen any indication that this has
My feeling is that the way to do what you want will involve some of
1. a terminal server to convert the serial lines to ethernet and
2. Use of a non-Linux system like SCO which supports smart serial
3. waiting for someone to port a smart card server to Linux.
4. connection of several systems with fewer users per system, and
files shared via NFS.
As far as I know you can't just put that many connections on Linux as
it stands right now, and I'm pretty sure that you would not be happy
with the result even if you could.
Oh, and I would count on remote boot, if the system gets wedged to the
point where it needs booting, you might have to have an outside access
to it, like the power switch or some such. Fortunately getting systems
to run months or years between boots is pretty cheap these days.
From: ty...@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: SUMMARY: Linux and Large Systems
Sender: dae...@athena.mit.edu (Mr Background)
Reply-To: ty...@ATHENA.MIT.EDU (Theodore Ts'o)
Organization: The Internet
Date: Thu, 15 Oct 1992 03:37:17 GMT
William E. Davidsen writes:
|I don't believe Linux will do this. I haven't looked at the sources in
|the last month, but the old sources included a limit of 64 as the
|highest process number, and I haven't seen any indication that this has
There are a number of reasons why Linux (running on a 386/486 with the
ISA bus) isn't the best suited for running 50-60 users, but the reputed
64 process limit is *not* one of them. In older versions of Linux, this
limit was a design limit, which could be increased without making
serious changes to the memory management system. Those changes have
since been made --- the same changes increased each process's address
space to 4 gigabytes --- and at this point, the 64 process limit is
merely a compile-time limit that can be easily increased by changing the
appropriate .h file and recompiling.
USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.
SCO Files Lawsuit Against IBM
March 7, 2003 - The SCO Group filed legal action against IBM in the State
Court of Utah for trade secrets misappropriation, tortious interference,
unfair competition and breach of contract. The complaint alleges that IBM
made concentrated efforts to improperly destroy the economic value of
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services
business. See SCO vs IBM.
The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
Electronic mail: WorldWideWeb: