CSE 515 | Homework 2

CSE515 Distributed Computing Systems

Winter 2004

Homework 2: Cost of Remote Communication

The Problem

Remote Communication is obviously more expensive than local communication. But how much more expensive?
The details of the answer depend on the software and hardware platform. However, it is still very useful to get a "feel" for the numbers on a platform that you use frequently. You have also seen Birrell & Nelson's numbers from 1983. What has changed in the intervening twenty years?

Remember, you don't have to understand all the details of the remote communicaiton package that you choose to measure. You can get away with modifying a canned example program.

What to do

I recommend forming a team. This assignment can be tone individually or in teams of two. You will get all of the benifits and will spend less time if you do this as a team. But, I am not requiring that you form teams.

Choose one of

Sun RPC

Java RMI

CORBA

any other RPC or RMS (Remote Message Send) package in which you are interested or with which you are familiar. So, if you are a Smalltalk or Haskell affecionardo, take the opportunity to find out what packages are available for that platform, and measure one.

Measure the performance of

A null remote call with zero arguments and zero results.

A null remote call with 1 arguments and 1 result.
A null remote call with 2 arguments and 2 results.
A null remote call with 10 arguments and 10 results.
A null remote call with a 400 byte array as argument and a 400 byte array as result.

By null remote call I mean that the remote method or procedure does not do any work—the results are returned immediately.
These measurements are a subset of those reported by Birrell & Nelson in Table I. You may also measure any other combinations that you find interesting — if you wish you can reconstruct their whole table. But this is not required.

Perform these measurements

locally, i.e., with no RPC or RMS package involved
between two processes (in separate address spaces) on the same machine, and
between two processes on two different machines on the same LAN (e.g., church and state).
If you wish, and you have access to machines separated by a WAN, measure WAN performance too (e.g., between your home and OGI, or your work and your home.) If you do this, use traceroute (or similar program) to count network hops and to measure ping times between the machines.

Report information about the configuration that you test. What hardware, operating system version, network, etc. were you using. Can you estimate the load on the network?

Don't try and time one call. Time a batch of 100 or 1000 calls, to get a more precise result. For local calls (§4.1), you will probably have to time a million or more.

Repeat your measurements several times (say, 10), and report variances as well as means. Don't time the first batch of calls — these may be subject to "cold cache" effects.

What to turn in

Email a plain text (using tabs to set up the table, not visual formatting), HTML, PDF or Microsoft Excel document, as an attachment, to cse515-hw. Make sure that the names of all team members are on the turn-in document (and not just in the email).

Each team should hand in a table roughly in the format of Table I from the Birrell & Nelson RPC paper. All measurements should be reported in micorseconds (µs) per call.

Add notes to your table explaining any measurements that you feel need explanation. Again, the notes in Section 4 of Birrell & Nelson can be used as a guide.

Useful Resources

General

Notes from Tim Kindberg on measuring things in an Operating System (somewhat Unix-centric).

Sun RPC

RPC is part of SUn's "Open Network Computing" offering, called ONC+.

Sun ONC+ Developer's Guide (remote HTML | local pdf).

Java RMI

Sun's guide to getting started with RMI and Java RMI Tutorial from Northeastern University

CORBA ORBs

There are many free implementations of CORBA available. Previously, members of this class have reported success with ObjectSpace's (now Recursion Software's) Voyager.

	CSE515 Distributed Computing Systems Winter 2004

	Homework 2: Cost of Remote Communication The Problem Remote Communication is obviously more expensive than local communication. But how much more expensive? The details of the answer depend on the software and hardware platform. However, it is still very useful to get a "feel" for the numbers on a platform that you use frequently. You have also seen Birrell & Nelson's numbers from 1983. What has changed in the intervening twenty years? Remember, you don't have to understand all the details of the remote communicaiton package that you choose to measure. You can get away with modifying a canned example program. What to do I recommend forming a team. This assignment can be tone individually or in teams of two. You will get all of the benifits and will spend less time if you do this as a team. But, I am not requiring that you form teams. Choose one of Sun RPC Java RMI CORBA any other RPC or RMS (Remote Message Send) package in which you are interested or with which you are familiar. So, if you are a Smalltalk or Haskell affecionardo, take the opportunity to find out what packages are available for that platform, and measure one. Measure the performance of A null remote call with zero arguments and zero results. A null remote call with 1 arguments and 1 result. A null remote call with 2 arguments and 2 results. A null remote call with 10 arguments and 10 results. A null remote call with a 400 byte array as argument and a 400 byte array as result. By null remote call I mean that the remote method or procedure does not do any work—the results are returned immediately. These measurements are a subset of those reported by Birrell & Nelson in Table I. You may also measure any other combinations that you find interesting — if you wish you can reconstruct their whole table. But this is not required. Perform these measurements locally, i.e., with no RPC or RMS package involved between two processes (in separate address spaces) on the same machine, and between two processes on two different machines on the same LAN (e.g., church and state). If you wish, and you have access to machines separated by a WAN, measure WAN performance too (e.g., between your home and OGI, or your work and your home.) If you do this, use `traceroute` (or similar program) to count network hops and to measure ping times between the machines. Report information about the configuration that you test. What hardware, operating system version, network, etc. were you using. Can you estimate the load on the network? Don't try and time one call. Time a batch of 100 or 1000 calls, to get a more precise result. For local calls (§4.1), you will probably have to time a million or more. Repeat your measurements several times (say, 10), and report variances as well as means. Don't time the first batch of calls — these may be subject to "cold cache" effects. What to turn in Email a plain text (using tabs to set up the table, not visual formatting), HTML, PDF or Microsoft Excel document, as an attachment, to cse515-hw. Make sure that the names of all team members are on the turn-in document (and not just in the email). Each team should hand in a table roughly in the format of Table I from the Birrell & Nelson RPC paper. All measurements should be reported in micorseconds (µs) per call. Add notes to your table explaining any measurements that you feel need explanation. Again, the notes in Section 4 of Birrell & Nelson can be used as a guide. Useful Resources General Notes from Tim Kindberg on measuring things in an Operating System (somewhat Unix-centric). Sun RPC RPC is part of SUn's "Open Network Computing" offering, called ONC+. Sun ONC+ Developer's Guide (remote HTML \| local pdf). Java RMI Sun's guide to getting started with RMI and Java RMI Tutorial from Northeastern University CORBA ORBs There are many free implementations of CORBA available. Previously, members of this class have reported success with ObjectSpace's (now Recursion Software's) Voyager.