🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: fa.works
Article #48

General Works comments

#48
From: ucbvaxworks
Date: Sat, 20 Feb 1982 18:30
83 lines
5537 bytes
>From ROSSID@WHARTON-10 Sat Feb 20 18:03:16 1982
Hi:

   I'm a new WorkS member, having spent last night reading the archives.  I'm a
member of the Office Systems Technology Division of a Fortune 10 corporation,
involved in internal office automation consulting for the corporation,
worldwide.  My group has a good bit of experience with "workstations," and we
currently have a group of Stars on an Ethernet, some Apollos on Domain, and I am
typing this in via a Datapoint on an ARC LAN.  My particular interests are in
workstations in an office environment, integration of workstation functions, and
local area networks.

First, some observations, which also serve to answer some questions that people
have raised thus far:

1) What is a workstation?  I  consider a workstation a single-user (interactive)
   computer.  I expect most "interesting" workstations (e.g. those we want to
   talk about) will also have the following functionality:  high resolution
   display, "interesting" user interfaces (e.g. CAT, mouse, tablet, touchpanel,
   etc.), CPUs more powerful than the Z-80, and local area network capabilities.

2) On LAN speeds (someone asked why it mattere).  After a good deal of
   research, I consider the question of speed of an LAN to be similar to the
   question of how good a roadbed a highway has.  What that means is it is
   @i(potentially) easier to go faster down a well paved highway than one with
   potholes, and it is @i(potentially) easier to utilize a workstation which is
   connected via a fast (10MB+) LAN.  However, this does not mean that you can't
   go fast on a crummy highway, or inch along on a highway made like the
   Autobahn for that matter; the speed YOU travel is a function mostly of the
   car you drive, not so much of the condition of the highway.  Likewise, the
   workstation, its configuration, and its architecture are the primary factors
   in determining the its functionality, not the network it is connected to.  It
   is not particularly relevant to simply examine, say, an Ethernet, without
   understanding what you will be attaching to it, and how the system will be
   used.  For example, think of how a system where workstations have local
   storage (connected directly, off the LAN) in addition to a filerver (on
   the LAN) in contrast to workstations which rely entirely on a file server.
   In the former, the workstation need not access files over the LAN too often,
   and in fact, the local storage could be "intelligent" and serve as a sort of
   cache memory, automatically downloading from the file server what it thinks
   the user might require next.  I would not be at all surprised if under this
   type of workstation configuration, a twisted pair (standard telephone wire)
   9.6KB connection would serve all non-interactive voice/video applications.


3) On why we need a 10MB or greater LAN -- in fact, as the above comments
   explain, we probably don't.  That 10MB was formulated given the following
   assumptions: a high resolution, bit mapped screen (1,000 by 1,000 is 1MB), a
   typical network utilization rate of 10% (that is, since the network is a
   shared resource, we assume we only get a 10% piece of the pie), and no local
   storage.  Now, if we have a maximum tolerated response time of 1.5 seconds to
   put up a page on our screen (studies suggest that 1.5 seconds, if constant,
   is a pretty good guestimate) we need an LAN speed of:

    1000x1000B(screen size) x 10(utilization factor) / 1.5 sec =

   about 6.6MB, which we round up to about 10 MB since all the numbers were
   pulled out of a hat anyway and we just wanted an order of magnitude.  As
   mentioned above, notice most of the assumptions made are functions of the
   @i(workstation) design.  The primary assumption is that we would want to go

   directly from file server on the LAN to the workstation screen, without using
   the local storage as buffer/cache.  Other assumptions include: no compression
   algorithm in the bit mapped display (or even the fact that a bit mapped
   display is required), and network utilization level of 10% (no-one really
   knows, but clearly the network will be required more if we always use the
   file server than if we have local storage, therefore higher utilization is a
   function of the workstation configuration too).

4) And now, a question -- anyone on this list from the SPICE project?  I had a
   PERQ demonstration last week, but they really didn't say anything of great
   interest.  I have a writeup done by another member of our staff which
   compares the two, concluding, as did I, that while there are some cute things
   in both, till there is any end-type software who cares!?  What I'd like to
   know from SPICE/SALT people is, is there any documentation available to
   non-CMU people on the project, where it is going, and what it is trying to
   do?  I know, for instance, that Three Rivers is getting Scribe to run on its
   machine, but evidently NOT in interactive mode a la Etude and Janus, but
   rather as the vanilla batch system, which is a real loss!  Is there a goal of
   interactive Scribe eventually?  What are time frames for releasible end-user
   products?

Well, that's it for now  --  Dave Rossien (ROSSID@WHARTON)
Technical Details
Message-ID: <anews.Aucbvax.6242>
Path: arc1-ca.pugleaf.net!utzoo!decvax!ucbvax!works

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!decvax!ucbvax!works
From: ucbvax!works
Newsgroups: fa.works
Subject: General Works comments
Date: Sat, 20 Feb 1982 18:30:05 +0000
Message-ID: <anews.Aucbvax.6242>