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 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 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.