Changes between Initial Version and Version 1 of Internal/Xen

Timestamp:

Sep 28, 2006, 5:58:43 AM (18 years ago)

Author:

anonymous

Comment:

—

Internal/Xen

@@ +1 @@
+All these ideas are young and rough (9/28/2006).
+
+http://www.xensource.com
+
+= Potential Uses in Scheduling ORBIT =
+
+Xen ORBIT can be used to run simultaneous experiments without modifying (what amounts to) the experimenter's API.  In theory the Xen host could prevent experiments running in one guest from utilizing the radios at frequencies used by other simultaneous experiments.  This may require special support in the device driver, but then we're already putting "regulatory controls" in at the driver level, so in theory we could just define our own regulations for the ORBIT locale.
+
+A particular instance can be stopped, have its Xen image stored somewhere, and be restarted later.  More robust scheduling of experiments might therefore be possible.  While one experiment is running in a Xen guest, the host of that instance could simultaneously be downloading the image (imagezip or Xen) for the next experiment.  This opens up a lot of scheduling flexibility.
+
+= Potential Problems =
+
+Some of the above features may be difficult to engineer for experiments that use a lot of the grid.  It would probably require extremely well-tuned NAS connected to each node, among other things.
+
+Scheduling that starts and stops experiments will probably prohibit some class of experiments.  It's unclear which ones will be prohibited.
+
+Simultaneous experiments, or host preparations for the next experiment during the current experiment, mean experiments may no longer run in real time.  Granted, there is no hard real time scheduling in the operating systems running on the current nodes, but so long as the nodes are relatively unloaded they will probably run experiments fast enough so that you'll see similar performance as in the sandbox.  Delays from the ORBIT scheduler may become intolerable.
+
+There are broader issues with scheduling ORBIT experiments.  Presently there is no way to detect when a particular experiment has finished other than the experimenter observing it.  Often an experiment that runs on two nodes in a sandbox has significant problems when it hits the grid, and the experimenter needs interactive access.