Download The Little Work Project

--
--
The Little Work Project
P. Honeyman, L.B. Huston, and Jim Rees
Center for Information Technology Integration
The University of Michigan
Ann Arbor
INTRODUCTION
A significant trend in contemporary computing technology is the continuing micro-miniaturization of components. High-powered, microprocessor-based machines have moved from the desktop, to the laptop, to
notebook-sized, and now palmtop computers! These machines are distinguished in their hardware technology, but supporting software has not kept pace: the predominant operating system on such machines is
MS-DOS, absent any support for distributed computing. With the Little Work project, we propose to close
this gap in the information technology environment.
The goal of the Little Work project is to develop a portable computing environment, using off the shelf
components, capable of providing a work environment which is identical to the one we enjoy in our office.
To do this we need to select the appropriate building blocks for our system. Some of the pieces we have
identified as being critical are: the computer, the operating system, file system, and communications.
THE COMPUTER
The ideal portable computing platform should make no compromises except where required by space,
mass, and power considerations, e.g. a 19 inch screen (or more) is de rigueur on the desktop, but is impractical for a portable machine. Typical off-the-shelf components in today’s marketplace in fixed and portable
computers are shown in the following table.
MIPS
Display
Disk
Memory
OS
Comm
Fixed
20 ! 50
1000 × 1000
100 ! 500 MB
8 ! 32 MB
UNIX
10 Mbps
Portable
2 ! 10
640 × 480
20 ! 100 MB
1 ! 16 MB
MS-DOS
< 2 Mbps
With this in mind we have chosen to use intel 80386 based computer systems. Due largely in part to the
widespread availabilty of these types of portable machines.
OPERATING SYSTEM
The primary contribution of the Little Work project is enhancement of the operating system environment
for portable computing. Instead of MS-DOS, we have decided to run the Mach operating system[1]. This
--
--
provides us with a form of BSD Unix running on a on a 386 based computer. We chose this operating system because it was the closest thing to Unix which we could obtain in source code form. This component
may change as other versions of BSD Unix become available for the i386 platform.
FILE SYSTEM
A distributed file system (DFS) is essential for a machine with limited permanent storage. Additionly, a
DFS allows system administration to be centralized, so that the contents of disks on DFS clients don’t
require backup. Also, using a DFS allows us to operate in a ’dataless’ mode. This means that the only files
required to reside on local disk are the minimum required to boot the machine. The DFS is responsible for
providing all other files. This requirement means that the contents of the local disk are essentially worthless, and negates any need for doing backups.
Another requirement of our filesystem is to support some form of disconnected operation. We would like
the system to rely heavily on cached versions of files, and talk to the file servers as little as possible. In fact
we want to assume that the normal mode of operation will be in disconnected mode, and actual network
connections will be as limited as possible.
Coda[2, 3] would seem to be the obvious candidate, but is not yet publicly available. We also have a lot of
experience with AFS [4], both as users and as developers, so we decided to stick with that. However, AFS
provides strong coherency semantics requiring that the client be in constant contact with the file server.
We intend to modify the AFS client to ease these restrictions. This will be discussed in more detail below.
COMMUNICATIONS
To have a useful system, we need to provide some sort of data communications. This is necessary to support a DFS. It is also necessary to provide the ability to read mail and talk to other network services if the
portable environment is to be a replacement for our desktop environment.
While advances have been made in wireless technologies, they are still limited by the necessity to maintain
a close proximity to the transmitting stations, or data rates that are too slow. We decided for a truly mobile
system these requirements are too restrictive. Our decision was to use modems on standard voice grade
lines. We use two types of modems, normal land line based modems and cellular modems.
WHERE WE ARE
We have begun developing our prototype machine. We are currently using an IBM PS/2 Model L40,
based on a 20 Mhz 80386SX. It has a 640×480 VGA screen, just (barely) enough resolution to run X, and
can hold up to 18 Mbytes of RAM, more than we need. The disk, 60 Mbytes, is big enough to accommodate a healthy swap space (necessary for X!) and a adequate cache.
We are running Mach 2.5 from CMU. This provides us with a Unix like environment running X windows.
Therefore we are able to run all the applications that we would normally use at the office.
For data communications, we are currently using two types of modems. The first is a standard V32.bis
modem, with serial interface rates up to 57,600 bps. These modems still have a limited mobility because
they require a phone line. To further increase mobility we have a cellular modem based on Motorola cellular phone and a Telebit PEP modem. (PEP allows higher data transfer rates than normal modulation on a
cellular link.) Unfortunately the cellular modem is significantly slower, and more expensive than the land
based modems. A comparison of transmission rates for several types of files is listed below.
-2-
--
--
LITTLE WORK
File
type
compressed binary
binary
source code
Text
Land Based
(bytes/sec)
1
1
1
1
Cellular
(bytes/sec)
1
1
1
1
To economize on limited network bandwidth and substantial cellular phone charges, we have engineered
AFS to support compressed headers, based of Van Jacobsons’s TCP/IP header compression [5]. One serious problem first encountered with AFS is the inability of Rx [6], the RPC for AFS, to handle congested
networks — placing a 9.6 Kbps link into an otherwise high-speed network is a sure prescription for congestion. To fix this problem, Dave Bachmann has enhanced Rx, principally by following Van Jacobson’s
prescription for congestion avoidance and control [7]. This greatly increased our throughput by reducing
unnecessary retransmits. Some further work needs to be done to make Rx perform better under PEP.
By using the above system, we are able to produce a fair approximation of our desktop work environment.
Jim Rees has successfully ridden an Amtrack across the country, receiving and sending mail as he went
along. To do this he would wait till passing through an area with cellular coverage, open a network connection and pull down his mail. He would close the connection, and locally compose his replies. Then at
the next area with cellular service he would bring up the network and send his responses.
THE FUTURE
The largest difference between our portable environment and the fixed environment is the lack of distributed file service when the modems are not connected. This requires us to violate our basic rule of dataless
client. Currently when we want use a set of files on the portable machine we have two options. The first is
to establish a network connection and access those files using AFS. The second method is to explicitly
copy these files to our local disk, and restore them to AFS land at a later time. Neither of these methods
provide a satisfactory solution. The vision of Little Work would allow us to establish a network connection
and warm up our cache. Then we should be able to shut down the network and continue using the caches
files as if the network were up.
This disconnected operation is the part of Little Work that is currently being developed. Our strategy is to
take some of the optimistic cache consistency principles used in Coda and to apply them to AFS.
The basic idea behind this optimistic handling of the cache is for the cache manager to assume that things
are fine unless it can tell otherwise. When it must perform an operation that may result in some inconsistency, (ie. writing to a file) it logs enough information so that upon establishing a network connection
with the file server, the cache manager can see it is okay to perform this operation. If it is then the cache
manager can go ahead and make the changes to the file servers version of the file. If the operation would
cause some inconsistency, it will notify the user and let her make a decision about the appropriate course of
action.
Some of the main differences between the our method and Coda is that we do not want to modify the file
servers in any way. One reason for this requirement is to allow our portable environment to talk to any of
the ever growing number of AFS Files servers. This will allow us to use File Server which are out of our
administrative control. This requirement forces all of our work to be done on the client. This differs from
Coda, where the client needs to create a log, and when a network connection is established, the client sends
the log to the fileserver and the fileserver performs the cache reconciliation.
As of this writing we have implemented some of the basic disconnected operations. We are able to continue doing reads from our cache when we are no longer in contact with the file server. Additionly we are
also able to perform writes into the cached version of the file. We are currently working on the cache
reconciliation upon the reconnection of the network.
Additionally we would like to add some other functionality to the underlying operation system. One of of
our desires is to add a hibernate mode. In traditional Unix systems the computers are left on almost continuously, so there is no need for to provide quick restarts. However, in a portable environment this is no
-3-
--
--
Honeyman
longer the case, uptime of a system is limited by the battery life which is typically a couple of hours. We
would like to add the functionality of telling the system to hibernate. This would have the kernel swap out
all processes to disk, and save enough state information so that when the system was powered on again, in
would be able to come up in the same state it was in before the shutdown. This includes having the same
applications running.
Other technical challenges abound, such as application-level support for network reconfiguration, dynamic
IP address assignment, X windows over VGA, operating system assistance for (battery) power management, etc.
SUMMARY
The underlying thesis of the Little Work project is that laptop computers are now capable of supporting the
kind of distributed computing environments common in academia and industry. The Little Work project
makes a powerful statement in what is achievable today. Furthermore, it positions us to take advantage of
further enhancements in computing technology: better screens, denser memory and disks, digital cellular,
etc.
REFERENCES
1. Mike Accetta, Robert Baron, William Bolosky, David Golub, Richard Rashid, Avadis Tevanian, and
Michael Young, ‘‘Mach: A New Kernel Foundation for UNIX Development,’’ pp. 93!112 in Summer
1986 USENIX Conf. Proc., Atlanta (July, 1986).
2. Mahadev Satyanarayanan, James J. Kistler, Puneet Kumar, Maria E. Okasaki, Ellen H. Siegel, and
David C. Steere, ‘‘Coda: A Highly Available File System for a Distributed Workstation Environment,’’
IEEE Transactions on Computers 39(4), pp. 447!459 (April, 1990).
3. Mahadev Satyanarayanan and James J. Kistler, ‘‘Disconnected Operation in the Coda File System,’’
Proc. ACM SIGOPS ’91, Pacific Grove, CA, pp. 213!225 (October, 1991).
4. J.H. Howard, ‘‘An Overview of the Andrew File System,’’ pp. 23!26 in Winter 1988 USENIX Conf.
Proc., Dallas (February, 1988).
5. V. Jacobson, ‘‘Compressing TCP/IP Headers for Low-Speed Serial Links,’’ Internet Request for Comments, Menlo Park, CA(1145), Network Information Center, SRI International (February 1990).
6. ‘‘Rx: Extended Remote Procedure Call,’’ Proc. of the Nationwide File System Workshop, Pittsburgh,
Information Technology Center, Carnegie-Mellon University (August, 1988).
7. V. Jacobson, ‘‘Congestion Avoidance and Control,’’ Proc. ACM SIGCOMM ’88, Stanford, CA,
pp. 314!329 (August 1988).
-4-