Aucbvax.5830
fa.works
utcsrgv!utzoo!decvax!ucbvax!works
Mon Jan 18 13:25:40 1982
WorkS Digest V2 #9
>From JSOL@USC-ECLB Mon Jan 18 12:10:52 1982
Works Digest Monday, 18 Jan 1982 Volume 2 : Issue 9
Today's Topics: Page Size & Page Tables
Ways To Do Backups
Must Displays And Mainframes Share Memory?
----------------------------------------------------------------------
Date: 17 Jan 1982 0007-EST
From: WALKER at CMU-20C
cc: mo at LBL-UNIX
Subject: page size
While not wishing to extend the infinitely long discussion on
paging, I can't let the references to the VAX page size pass without
comment.
It is true that 8Mbytes is required for the system page table when the
process space is 2Gbytes. However you are confusing implementation
with architecture. Just because the VAX-11/780 has an 8Mbyte memory
limit doesn't mean that VAX-11/XXX will have such a limit. If you
also keep in mind that the architecture was designed to last a long
time, you will realize that 8Mbytes may be only a small percentage of
the physical memory space when 2Gbyte programs become common. This is
not to say that AI types have it easy right now.
If you are really worried about the page table space, it is possible
to add another level of indirection (and factor of 16 reduction in
space) by putting the system page table into the reserved part of
system space by modifying the architecture at a future date. I
doubt that it will ever happen. This is somewhat similar to
National's NS16000 scheme.
A small page size is good because it reduces internal fragmentation.
It can't be too small because it is your unit of communicating with
the disk. 512 bytes has been found to be a good compromise no matter
what any IBM studies say. 512 is definitely better than 1K or 2K.
In summary, think in 20 year time spans. The 360/370 has been around
nearly that long. The VAX will be too.
------------------------------
Date: 16 Jan 1982 21:24:58-PST
From: mo at LBL-UNIX (Mike O'Dell [system])
To: walker at cmu-20c
Subject: page size
If memory gets cheap enough to use 8 megs of page tables for EACH process,
you won't give a flip about internal fragmentation. You will still
be concerned about the amount of screwing with page tables the system
has to do.
Two gigabyte programs are very real things right now. VLSI rule checkers
and routing algorithms are just waiting for the extra address bits.
On a more religous level, I doubt seriously if the Vax will have
the lifetime of the 370. It is too easy to build better machines
these days, but that is fuel for a different flame on a different
mailing list.
-Mike
[Agreed - INFO-VAX@MIT-AI is the best place for such a discussion.
-JSol]
------------------------------
Date: 17 January 1982 1228-EST (Sunday)
From: Hank Walker at CMU-10A
Subject: backups
There are two basic ways to do backups if you are a small business.
The first is to have some removable media, such as a floppy or TU58
tape cartridge that you plug in periodically. The operating system
automatically handles incremental backups. It tells the user whenever
to insert a new cartridge. Intelligent encoding of backup data should
keep the typical daily backup down to 200K or so per workstation. The
OS should keep track of everything and just tell the user to do
something once per day or so.
The second alternative is for backups to be handled by your
maintenance contract. If the small business computer is hooked up to
cable TV, and so has a high-speed path to the field service office,
then backups take place rapidly. Naturally, encryption would be used
by the owner. If there are no cable links, then the machine can have
a 1200 baud modem, which requires about 1/2 hour to back up 200K.
Since you really only need half duplex, a 2400 baud modem would reduce
the time to 15 minutes. The field service center would call machines
in its area at night to perform backup to their large disks or tape.
Directories of backed up files would be left behind, or exist on disk
at the center. If the user needed a backed up file, the machine would
dial the center, request the file, and have it shipped over the phone
line.
Backup will only succeed if the user has almost no involvement, other
than doing the most trivial of things, such as "insert catridge
MONDAY", or "wait, fetching backup copy...".
------------------------------
Date: 17 January 1982 18:13-EST
From: Robert Elton Maas <REM MIT-MC AT>
Subject: What is a workstation?
Subject: Must works&display and main-cpu share memory?
To: George.Coulouris at CMU-10A
In order for the state as presented on the workststion screen to
be understandable to the human, it must be built upon a small
number of symbols each of which can be learned quickly, the
small number of symbols so that the total system can be learned
in a short time (a small number of quicklies, not a million
quicklies which can be a rather long training period).
That being assumed, it's easy to represent these symbols and
their locations on the screen (x,y offset, x,y scale, angle if
rotated, and which other symbols overlay them). That being the
case, it doesn't take much data to transmit updates to the screen
from the computer that's running the process to the word-processor
that's displaying it. Thus I see no reason to insist that the
whole system (cpu-intensive process, and workstation display)
run in shared mainframe memory. It is sufficient that they be able
to communicate over some halfway-reasonable network (perhaps 9600 baud).
Thus we design the workstation for editing, display, and network
communication, and leave the cpu-intensive tasks for the big machine
that is shared among seveal users.
------------------------------
End of WorkS Digest
*******************
-------
-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <
[email protected]>
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.
