Article View: comp.arch
Article #11316Re: IBM AS/400 is the world's slowest.. (actually multiuser systems)
From: Aaron Sloman
Date: Sat, 02 Jan 1993 11:54
Date: Sat, 02 Jan 1993 11:54
102 lines
5216 bytes
5216 bytes
mike@starburst.umd.edu (Michael F. Santangelo) writes:
> Date: 2 Jan 93 02:59:15 GMT
> Organization: University of Maryland, Chesapeake Biological Laboratory
>
> axs@cs.bham.ac.uk (Aaron Sloman) writes:
>
> >This discussion omits another option: instead of character-cell
> >terminals you can use X terminals connected to a powerful,
> >expandable, shared compute/file server. For many kinds of users this
> >combination provides most of the benefits of a workstation on each
> >user's desk but at a lower cost per user (including memory costs,
> >system management costs, etc.). ...
[stuff omitted]
> X-terminals are not themselves the cure-all either.
I agree, and tried to indicate this when I wrote
| > .....(Obviously some kinds of users
| >should not be on a shared machine, or should not have their screens
| >driven over a network ....
> .....Like diskless
> workstations they rely on decent networking as they produce quite a lot
> of network traffic.
For certain classes of users, e.g. people doing quite a lot of
----------------------------
editing, starting and stopping processes (compilers, editors,
linkers, various applications programs, etc.) a diskless workstation
will cause a lot *more* network traffic (reading in large executables
from the server, swapping, reading and writing files) than an X
terminal (for which the *only* network traffic is keyboard and mouse
signals and data to update the screen). (This can also be true of
workstations with small local disks, linked to a shared file server:
all they save is swapping and paging over the network. But they
have a bigger administrative cost than X terminals.)
If the interaction is mostly character based with occasional vector
graphics or bitmap displays, the network traffic per X terminal user
need not be high, though it will be higher than for a pure character
terminal. Of course if you have enough users on the same network any
class of terminal can generate too much network traffic.
>..Ethernet with its CSMA/CD architecture and 10Mb/sec
> bandwidth can be brought to its knees with these devices when the usage
> is moderate or more (depending as well on the # of stations).
Yes. But what I am saying is that (for most(?) sorts of users) the
amounts of network traffic generated can approximately be ordered
thus:
workstations > X terminals > character terminals
What is not always appreciated is that even if the workstations have
local disks they can still generate more net traffic than X
terminals if all users share a common file store, which is often
essential e.g. because local disks are small.
> ....At
> least with multiuser systems the terminal equipment was all character
> based using I/O controllers that were often distributed (multipoint)
> for the big guys or point-to-point between the terminal and the multiuser
> computer systems.
And now with X terminals, faster communications, more powerful and
*expandable* servers, etc. we can go back to that model but with far
higher functionality for the same overall cost. The dominant dogma
nowadays seems to be that "distributed processing is most
beautiful". All I am trying to do is undermine that as an
unqualified generalisation. Each pattern of use has to be analysed
carefully.
> The world of OLTP is a far different than academic/college environments.
> I've been in both.
I agree that different environments have different requirements. I
suspect that many commercial/industrial/administrative environments
could benefit as much from the server + X terminal architecture as
academic environments. (And of course not all academics are best
suited by this, depending on what they are doing.)
> There is no one-solution-fits-all. The best approach is to use the right
> solution and implement a very supportive underlying networking
> infrastructure. Some of the older connectivity ideas still have their
> place and are more suited to the job than some of the more modern ones.
We seem to be in complete agreement!
> Michael F. Santangelo + Internet: mike@cbl.umd.edu [work]
> Computer & Network Systems Head + mike@kavishar.umd.edu [home]
> Univ MD: CEES / CBL (Solomons Island) + BITNET: MIKE@UMUC [fwd to mike@cbl]
Aaron
---
--
Aaron Sloman, School of Computer Science,
The University of Birmingham, B15 2TT, England
EMAIL A.Sloman@cs.bham.ac.uk OR A.Sloman@bham.ac.uk
Phone: +44-(0)21-414-3711 Fax: +44-(0)21-414-4281
Technical Details
Message-ID:
<C086Et.Fx7@cs.bham.ac.uk>Path:
arc1-ca.pugleaf.net!sparky!uunet!pipex!bnr.co.uk!uknet!bhamcs!axsReferences:
<1992Dec21.141558.18626@rchland.ibm.com> <id.HD1W.X03@ferranti.com> <1992Dec26.003022.25532@bilver.uucp> <id.TX9W.FC3@ferranti.com> <1993Jan1.102554.28575@metapro.DIALix.oz.au> <C07DK0.E7t@cs.bham.ac.uk> <1i30e3INNksu@cbl.umd.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!pipex!bnr.co.uk!uknet!bhamcs!axs From: axs@cs.bham.ac.uk (Aaron Sloman) Newsgroups: comp.arch Subject: Re: IBM AS/400 is the world's slowest.. (actually multiuser systems) Message-ID: <C086Et.Fx7@cs.bham.ac.uk> Date: 2 Jan 93 11:54:28 GMT References: <1992Dec21.141558.18626@rchland.ibm.com> <id.HD1W.X03@ferranti.com> <1992Dec26.003022.25532@bilver.uucp> <id.TX9W.FC3@ferranti.com> <1993Jan1.102554.28575@metapro.DIALix.oz.au> <C07DK0.E7t@cs.bham.ac.uk> <1i30e3INNksu@cbl.umd.edu> Sender: news@cs.bham.ac.uk Organization: School of Computer Science, University of Birmingham, UK Lines: 102 Nntp-Posting-Host: emotsun