Question 4 of 7: Operating Systems for Distributed Architectures

Question 4: Operating Systems for Distributed Architectures (20 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Given (a). Client compute time per request 5 ms; server processing time per request 10 ms; local OS send/receive processing 0.5 ms per operation; network transmission 3 ms per message (request or reply); marshalling/unmarshalling 0.5 ms per message; two RMI calls to estimate, single-threaded vs. two-threaded on one client processor.

Find. Total elapsed time for the client to issue and complete two RMI calls, single-threaded and two-threaded; whether async RMI adds anything once the client is multi-threaded.

Approach. Split each RMI round trip into the segments that use the client's own CPU (compute, marshal request, OS send, OS receive, unmarshal reply) versus the segments that happen off the client CPU (network out, server receive/unmarshal/process/marshal/send, network back); a single-threaded client must serialize both parts of the two calls, while a second thread can use the client CPU during the first call's off-CPU wait.

1. One RMI round trip. Client CPU segments: compute (5) + marshal request (0.5) + OS send (0.5) + OS receive (0.5) + unmarshal reply (0.5) $= 7.0$ ms. Off-CPU segments: network out (3) + server OS receive (0.5) + server unmarshal (0.5) + server processing (10) + server marshal (0.5) + server OS send (0.5) + network back (3) $=18.0$ ms. $$\boxed{\text{RTT}_1=7.0+18.0=25.0\ \text{ms}}$$
2. (i) Single-threaded, two requests. A single thread's RMI call blocks until the reply returns, so the second call cannot begin until the first fully completes: $$\boxed{T_{single}=2\times25.0=50.0\ \text{ms}}$$
3. (ii) Two threads, one client processor. Splitting each call's client-CPU work into a 6 ms pre-send slice (compute + marshal + OS send) and a 1 ms post-receive slice (OS receive + unmarshal): Thread 1 occupies the CPU from $t=0$ to $t=6$ and sends its request, then waits off-CPU for 18 ms while the CPU sits free. Since the off-CPU wait (18 ms) is longer than a whole pre-send slice (6 ms), Thread 2 runs its own pre-send slice on the now-free CPU from $t=6$ to $t=12$ and sends its request at $t=12$, with no CPU contention between the two threads. Thread 1's reply lands at $t=6+18=24$; the CPU is free (Thread 2 is off-CPU waiting), so Thread 1 finishes its 1 ms post-receive slice at $t=25$. Thread 2's reply lands at $t=12+18=30$, and it finishes its own post-receive slice at $t=31$ (CPU free by then). $$\boxed{T_{2\text{-thread}}=\max(25,\,31)=31.0\ \text{ms}}$$ Assumption: the server has enough capacity to process both requests without one queuing behind the other (e.g. a multi-threaded or multi-processor server); the client's own single CPU is the only serialization constraint being modelled.
4. Is asynchronous RMI needed if the client is multi-threaded? No, not strictly. The whole point of asynchronous (non-blocking) RMI is to let the caller keep doing useful work while a call is outstanding instead of stalling on it; a multi-threaded client already achieves exactly that effect — one thread blocks synchronously on its RMI while other threads proceed with other work, including issuing their own RMIs, as shown by Thread 2 running while Thread 1 waits above. Asynchronous RMI remains useful mainly when creating a thread per outstanding call is too heavyweight for the number of concurrent calls needed, or in a client design (e.g. single-threaded, event-driven) that cannot spawn a thread per call at all.

Given (b). Network transmission time is 20% of the total time for a null RPC (no user data) and 80% of the total time for an RPC transmitting 800 user bytes; the network is upgraded from 5 Mbps to 100 Mbps.

Find. The percentage improvement in total time for each of the two RPC types after the upgrade.

Approach. Treat total RPC time as split into a network-transmission fraction $f$ (which scales inversely with link speed) and a fixed non-network fraction $(1-f)$ (marshalling, OS processing, server computation — unaffected by the network upgrade); a $20\times$ faster network divides only the network-time fraction by 20 (Amdahl's-law form).

1. Speed-up factor. $$S=\dfrac{100\ \text{Mbps}}{5\ \text{Mbps}}=20$$
2. Null RPC ($f=0.20$). New relative time $=(1-0.20)+\dfrac{0.20}{20}=0.80+0.01=0.81$ of the original. $$\boxed{\text{Improvement}_{null}=(1-0.81)\times100\%=19\%}$$
3. 800-byte RPC ($f=0.80$). New relative time $=(1-0.80)+\dfrac{0.80}{20}=0.20+0.04=0.24$ of the original. $$\boxed{\text{Improvement}_{800B}=(1-0.24)\times100\%=76\%}$$

The 800-byte RPC improves far more because its total time is dominated by network transmission, exactly the part the upgrade speeds up; the null RPC's time is dominated by fixed marshalling/processing overhead the network upgrade cannot touch, so even a 20× faster link barely moves its total time — a direct illustration of Amdahl's law: speeding up only the fraction $f$ of a task by factor $S$ bounds the overall speed-up to $1/((1-f)+f/S)$, which saturates well below $S$ unless $f$ is close to 1.