<!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>
<My comments are prefixed with RR>.<br>
<br>
RR: I am in agreement. <br>
<pre wrap="">Is is possible that we will have certified a configuration without
knowing how to schedule it? That would mean that we somehow have
established (to within reasonable certainty) that the configuration can
be scheduled, but we don't know a schedule for it. Is that possible?
Well, he said answering his own question, in very relaxed circumstances
(not too much processing going on) it is possible to know that a
schedule exists without constructing one. But in this case the run-time
schedule construction is pretty easy, isn't it?</pre>
RR: You raise two good questions. Regarding knowing a schedule, I am
assuming that we will have a scheduler that generates a dynamic
schedule (for example using a priority-driven preemptive scheduler with
fixed or dynamic task priorities - Java supports preemptive scheduling
using fixed priorities). Static timelines (cyclic executives) cannot
be used, I think. If the static schedule were to be generated online
to cater to the dynamic system being certified online, then that would
really correspond to a dynamic online scheduler. The static schedule
however would have low overheads once generated (though I am of the
belief that for known/practical scheduling schemes, scheduling
overheads are no longer an issue of concern). Secondly, if the load
is low, the configuration constructor would indeed find lots of
feasible configurations. The practical suggestion would be to still
run the tests during the construction phase (just in case). Feasible
configurations would be found very quickly in the case.<br>
<blockquote type="cite">
<pre wrap="">We can (and should) take care of
requirements such as schedulability in the bin-packing phase.
</pre>
</blockquote>
<pre wrap=""><!---->
That means while we're sailing on the Cubicle Sea, right? If so, do you
mean that we shouldn't even test a configuration that fails the
schedulability test? As I recall, these tests can be pretty
conservative. (I don't know what the right answer is here, I'm just
askin'....)</pre>
RR: I wouldn't recommend testing a configuration that fails the
schedulability test. Often, the set of possible execution sequences
is infinite in number (due to any number of relative phasings among
tasks in addition to varying task execution times) and a very small
number could
miss their deadlines. Testing and finding those few cases would be
very expensive, if at all possible. Actually, this is more of a
statement that real-time systems should be analyzed for schedulability,
leading to a significant reduction in testing costs.<br>
<br>
RR: Yes, some schedulability tests can be conservative (particularly in
the
distributed end-to-end timing cases), but run-time mechanisms (a good
example is a release guard or period enforcer) are available to enforce
execution patterns - these reduce pessimism significantly and also
improve schedulability.<br>
<br>
<blockquote type="cite">
<pre wrap="">...and (c) the policies/mechanisms of the
run-time infrastructure should match the assumptions of the
bin-packing phase.
</pre>
</blockquote>
<pre wrap=""><!---->
If I might insert a step, how about: The policies/mechanisms of the
configuration construction machinery [which includes bin-packing] should
match those of the test environment, and the policies/mechanisms of the
test environment should match those of the run-time infrastructure.</pre>
RR: Your wording is accurate and should be the preferred one.<br>
<br>
Thanks,<br>
<br>
---<br>
Raj<br>
<br>
Cross, Joseph wrote:
<blockquote
cite="mid7FC402934595684AB4B49D416EF3D578021A2131@sde2k3-mb2.darpa.mil"
type="cite">
<pre wrap="">Raj -
Thank you for your always insightful comments. A couple of questions:
</pre>
<blockquote type="cite">
<pre wrap="">We can (and should) take care of
requirements such as schedulability in the bin-packing phase.
</pre>
</blockquote>
<pre wrap=""><!---->
That means while we're sailing on the Cubicle Sea, right? If so, do you
mean that we shouldn't even test a configuration that fails the
schedulability test? As I recall, these tests can be pretty
conservative. (I don't know what the right answer is here, I'm just
askin'....)
</pre>
<blockquote type="cite">
<pre wrap="">I also believe that an appropriate run-time infrastructure
is needed to (a) schedule the various processes/threads to
meet their deadlines when run concurrently
</pre>
</blockquote>
<pre wrap=""><!---->
Is is possible that we will have certified a configuration without
knowing how to schedule it? That would mean that we somehow have
established (to within reasonable certainty) that the configuration can
be scheduled, but we don't know a schedule for it. Is that possible?
Well, he said answering his own question, in very relaxed circumstances
(not too much processing going on) it is possible to know that a
schedule exists without constructing one. But in this case the run-time
schedule construction is pretty easy, isn't it?
</pre>
<blockquote type="cite">
<pre wrap="">...(b) enforce/isolate the run-time behaviors of each
process/thread,
</pre>
</blockquote>
<pre wrap=""><!---->
Totally agree. This kind of isolation will be key to our 'projection'
operation.
</pre>
<blockquote type="cite">
<pre wrap="">...and (c) the policies/mechanisms of the
run-time infrastructure should match the assumptions of the
bin-packing phase.
</pre>
</blockquote>
<pre wrap=""><!---->
If I might insert a step, how about: The policies/mechanisms of the
configuration construction machinery [which includes bin-packing] should
match those of the test environment, and the policies/mechanisms of the
test environment should match those of the run-time infrastructure.
- Joe
</pre>
</blockquote>
<br>
</body>
</html>