Text File

Aucbvax.6242 fa.works utcsrgv!utzoo!decvax!ucbvax!works Sat Feb 20 18:30:05 1982 General Works comments >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)

----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org> of http://communication.ucsd.edu/A-News/

This Usenet Oldnews Archive article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.