[cadynce] How Many Configurations Is Enough?

[Raj Rajkumar]

Gautam:

Thanks for the update.  Given the confines of "Box 2", it does seem that 
we should be generating a *lot* more allocations, and testing them 
efficiently.

I would add however that even in Box 2, the number of possible schedules 
is very very large.  Each time a task or a job starts or arrives later, 
and each time it executes shorter than its worst-case execution time 
(which is almost always), the run-time behavior is indeed different.  
However, thanks to scheduling analyses and such, we know that in the 
worst-case, the timing constraints will be met.  So, it would seem to me 
that parts of "Box 2" already overlap into the space of "Box 3".   A 
true-blue "Box 2" system would perhaps use strict timelines (cyclic 
executives) with no asynchronous activity of any kind.

My 2 cents.

---
Raj

Gautam Thaker wrote:
> Raj Rajkumar wrote:
>> Dear Joe:
>>
>> 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
>>
>>    1. Generate feasible configurations on the fly given constraints at
>>       that point in time.   Since the space of configurations can be
> Hi Raj:
>
> In my classification of DRM systems "on the fly" would count as "Box 
> 3". Current approaches are based on "Box 2", which is to generate all 
> certified allocations before hand. "Box 3" (on the fly generation) is 
> easier at times, but would require enormous extra work of certifying 
> the  allocators themselves (this is viewed as bridge too far for now, 
> the worry is that Navy would be afraid fo this and I would agree.)
>
> Gautam
>
>>       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.
>>    2. 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.
>>
>> Thanks,
>>
>> ---
>> Raj
>>
>> Cross, Joseph wrote:
>>> Gentledudes -
>>>
>>> On
>>> https://escher.isis.vanderbilt.edu/twiki/bin/view/CADYNCE/Configurations 
>>>
>>> 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
>>> joseph.cross at darpa.mil
>>> (571) 218-4691
>>>  
>>> _______________________________________________
>>> Cadynce mailing list
>>> Cadynce at list.isis.vanderbilt.edu
>>> http://list.isis.vanderbilt.edu/mailman/listinfo/cadynce
>>>   
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Cadynce mailing list
>> Cadynce at list.isis.vanderbilt.edu
>> http://list.isis.vanderbilt.edu/mailman/listinfo/cadynce
>