\section{Machine model}
\label{sec:mach_model}

Our machine model corresponds to the real world computing environments
that most people have access to.  In particular, we assume host
computers interconnected by a local area network.  The host computers
have no centralized scheduler or coordinated scheduling mechanism and
their local schedulers do not support reservations or real-time
scheduling.  Similarly, the network does not support any sort of
reservation scheme.  The hosts execute independent tasks that generate
traffic on the network.  This is, of course, a description of any
modern group of workstations or PCs.

%It is important to note that we do not preclude computing environments
%that have sophisticated scheduling or reservations and run
%non-independent tasks, merely that we do not assume their existence
%and we must not be bound by them.  In particular, an environment that
%migrates executing tasks or undermines our initial placement decisions
%cannot be supported.

In addition to these commonplace features, we also assume the
existence of two extensions.  The first is a remote execution facility
that makes it possible to seamlessly execute any procedure in the
program on any host.  The second extension we assume is a measurement
facility.  The core requirement is that we must have access to a
real-time clock on each host that is precise down to the overhead time
of the remote execution facility (1 ms for most current systems,
conceivably as low as 1 $\mu$s for future systems.)  Currently, we
expect only to be able to accurately measure the execution times of
remote procedure calls.  However, it may also be useful to be able to
measure the constituents of that execution time, such as host load and
available network bandwidth.  Ideally, it would be possible to measure
load and network traffic at the clock granularity and make this
information available to every host in the system.  However, we also
require that any such measurement system should not significantly
perturb the system.  In terms of performance, it should not use more
than a small, known fraction (5\%, for example) of available cycles
and communication bandwidth, and should not exhibit any feedback
effects that would falsely inflate or deflate its measurements.



%In particular, we require a primitive of the form
%\begin{center}
%\EXECUTE \texttt{procedure(inargs, outargs, inoutargs, state)} 
%    \ONHOST \texttt{h} 
%\end{center}
%This primitive may be supplied by an RPC mechanism, a distributed
%object system, a distributed shared memory system, or some other kind
%of software or hardware system.  We intend to eventually incorporate
%our research into the LDOS distributed object system which provides
%this kind of facility.