wiki:GeniTutorialHints

Suggestions for Running Hands-On GENI Tutorials

The suggestions on this page are based on experiences with hands-on GENI tutorials at the GECs. The suggestions are fairly generic; you'll need to tailor them for your tutorial.

Please send your questions or comments on this page to Vic Thomas or Niky Riga.

Before the Tutorial

  1. Tutorial objectives, description and pre-requisites. The abstract used to advertise your tutorial should provide a clear statement of its objectives (e.g. "At the end of the tutorial attendees will be able to set up an experiment that connects geographically distributed resources using a non-IP protocol"), a concise description of the tutorial and any pre-requisities (e.g. "Attendees must be proficient in COBOL" or "Attendees must come with computers running a browser that supports Adobe Flash").
  2. Number of attendees. The number of attendees you can accommodate is usually limited by the availability of resources. A typical hands-on GENI tutorial at the GECs has 40 attendees working in pairs. You'll therefore need to ensure you have enough resources for 21 simultaneous tutorial exercises (for the 20 pairs of attendees and for the instructor).
  3. Assistants. It is very helpful to have at least two assistants available to wander around the classroom helping attendees that run into difficulties.
  4. Ensuring resources availability. Please coordinate with the resource owners (aggregate owners) to make sure the resources you need will be available when you need them. Aggregate providers may be willing to set aside resources for exclusive use by your tutorial.
  5. Client software on attendee machines. If you need special client side software (e.g. GENI experiment control tools) installed on the attendee machines, it might be best to pre-install this software in a virtual machine and distribute this virtual machine for the attendees to run on their computers. We've very successfully used VirtualBox for this purpose: All client-side software needed by the attendees is installed in a VirtualBox virtual machine running an OS such as Ubuntu. Attendees are asked to come with VirtualBox installed on their computers. They can install the virtual machine with tutorial software at the tutorial or ahead of time. We strongly encourage making the virtual machine image available to attendees ahead of time so valuable class time isn't spent installing the virtual machine image. Additionally, these virtual machine images tend to be large (many GBs) and so downloading and installing them during the tutorial might stress the network in the classroom.
  6. Experimenter credentials. Setting up experimenter credentials, creating and installing ssh keys, etc. can be very time consuming. So, unless an objective of your tutorial is to work through this process, we recommend creating credentials and installing the necessary keys ahead of time. Some tutorials have created multiple user accounts on the virtual machine and have installed the necessary certificates and keys for each account. Others have installed multiple sets of credentials in one virtual machine user account and have told each attendees which set of credentials they should be using.
  7. Dry runs. Dry run the tutorial. If at all possible, do the dry-run with 20 people (or whatever your expected class size may be) doing the exercises simultaneously so you can identify resource bottlenecks and concurrency issues.
  8. Post tutorial material online. Make your slides and other material (including experimenter software) available online.
  9. Hard copies of presentation material. Make a sufficient number of hardcopies of the presentation material available for distribution to all attendees. Hardcopies are especially helpful for attendees falling behind as they can try to catch up even if the instructions they need are no longer on the projector screen in front of the classroom.

During the Tutorial

  1. Seating. Make sure attendees are seated in pairs and they understand that each pair will be working together on the tutorial exercises. We've had situations where this wasn't made clear and both members of the pair worked independently on the exercises. This resulted in the class using more resources than planned.
  2. Introduction. Go over the objectives of the tutorial, a description of the experiment(s) that will be run during the tutorial, and the major steps in setting up and running the experiment(s).
  3. Managing bottlenecks. Certain steps in the experiment workflow such as slice creation tend to bog down servers such as slice controllers, especially if you have 20+ simultaneous requests to create slices. Experience has shown it best to divide the class into three groups and stagger the start of the exercises. For example, group 1 starts by issuing their slice creation requests and group 2 issues their requests after the slices for group 1 are created. Staggering also distributes over time the requests for help from the attendees.
  4. You are here. At the start of each major step in an exercise, be sure to remind the attendees what they've completed so far and what they'll be doing in the next step.
  5. Continuing experimentation. Make sure attendees leave knowing where they can find more information about the material covered in the tutorial and how they can get the accounts and credentials needed to try the exercises on their own.

After the Tutorial

  1. Clean up. Make sure all slices created during the tutorial have been deleted and all resources freed up. Any temporary accounts created for the tutorial must be deleted.
  2. Follow up. Ensure user guides/documents/examples related to the material covered in the tutorials are up to date. If necessary, update the online versions of the presentation and other material used during the tutorial.
Last modified 12 years ago Last modified on 10/11/11 17:42:11