<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dear Joe:<br>
<br>
These are very interesting analytical results. Ideally, we should
keep going until the last machine is standing (ignoring I/O for this
discussion). To tolerate such a high failure rate, your results show
that we need to store many more configurations (orders of magnitude
more). Given that we cannot test a huge number of configurations
offline, it seems to me that we should have the ability to <br>
<ol>
<li>Generate feasible configurations on the fly given constraints at
that point in time. Since the space of configurations can be large -
albeit with scaling back requirements or running only the most critical
tasks that would fit, we should be able to find one. We do not have to
find a feasible configuration if it exists; we just have to find a
reasonable one that will run under the given constraints.</li>
<li>Assuming that the generated configuration in Step 1 has utilized
appropriate scheduling analysis etc., we need to have a high degree of
confidence that the dynamic run-time configuration we chose will indeed
run as predicted. In that sense, we may want to run experiments where
a configuration generator is used to generate configurations that have
'never' been tested, and show that it can be run. A 'tester' must be
able to choose an arbitrary configuration by tweaking parameters or
making some simple moves or swaps from a given configuration. As has
been discussed before, the run-time environment must be adequately
reflected in the analytical model used during the generation of
feasible configurations.</li>
</ol>
Thanks,<br>
<br>
---<br>
Raj<br>
<br>
Cross, Joseph wrote:
<blockquote
cite="mid7FC402934595684AB4B49D416EF3D578021A227B@sde2k3-mb2.darpa.mil"
type="cite">
<pre wrap="">Gentledudes -
On
<a class="moz-txt-link-freetext" href="https://escher.isis.vanderbilt.edu/twiki/bin/view/CADYNCE/Configurations">https://escher.isis.vanderbilt.edu/twiki/bin/view/CADYNCE/Configurations</a>
LoadsAndPerformance is a new section that quantifies computing system
survivability as a function of the degree of damage to the computing
plant and the number of configurations in our certified set.
Bottom line is that the good news for CADynCE is that if the computing
plant suffers 20% damage, then the difference between a set of 10 and a
set of 1000 allocations is the difference between life and death; the
bad news is that for 10% or less damage, and for 30% or more damage,
there is no material difference between 10 and 1000 allocations.
- Joe
____________________________________
Dr. Joseph K. Cross, Program Manager
DARPA/IXO, room 612
3701 North Fairfax Drive
Arlington, Virginia 22203-1714
<a class="moz-txt-link-abbreviated" href="mailto:joseph.cross@darpa.mil">joseph.cross@darpa.mil</a>
(571) 218-4691
_______________________________________________
Cadynce mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cadynce@list.isis.vanderbilt.edu">Cadynce@list.isis.vanderbilt.edu</a>
<a class="moz-txt-link-freetext" href="http://list.isis.vanderbilt.edu/mailman/listinfo/cadynce">http://list.isis.vanderbilt.edu/mailman/listinfo/cadynce</a>
</pre>
</blockquote>
<br>
</body>
</html>