🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11316

Re: IBM AS/400 is the world's slowest.. (actually multiuser systems)

#11316
From: Aaron Sloman
Date: Sat, 02 Jan 1993 11:54
102 lines
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!axs
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>

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