<!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">
Hi Alan, Patrick and Gautam:<br>
<br>
Can we have a short discussion about computing e2e times in general? I
apologize if this was discussed in some recent meetings and/or
telecons; I may not have been present when these discussions occurred.<br>
<br>
Clearly, e2e delay is a sum of delay components along the entire path
(processors and links) of an application string. There are worst-case
and average-case considerations.<br>
<br>
Beyond the above, real-time scheduling theory holds that when
individual components have different arrival rates (e.g. periods),
execution times and a scheduling policy (preemptive or not, fixed
priority or not), the response time for a task on a processor (or a
communication link) is a function of not just utilizations but also the
individual parameters (C's and T's of the task at hand + all its higher
priority tasks, not just the total utilization). Just having e2e
times be a function of utilizations runs counter to scheduling theory
(+ real measurements, one would argue).<br>
<br>
Thoughts? Thanks,<br>
<br>
---<br>
Raj<br>
<br>
Alan F. Karr wrote:
<blockquote cite="mid465442E1.8040306@niss.org" type="cite">Patrick,
<br>
<br>
This is an investigation the extent to which the CPU utilizations given
the the models predict the measured end-to-end times (averaged over
messages--we will do the worst case times today). Everything is
restricted to the critical path. The model is in R-like notation: the
six CPU utilizations are the predictor (independent) variables. The six
coefficients are implied. I've revised the PPT to try to make this a
bit clearer, and will put it on the wiki. It's also attached, since
it's so small.
<br>
<br>
--- Alan
<br>
<br>
Patrick Lardieri wrote:
<br>
<blockquote type="cite">Hi Alan,
<br>
<br>
Interesting thoughts that I am not sure I understand fully.
<br>
<br>
At the 100,000 ft level it seems you are offering an alternative to
scheduling theory to predict the response time. Specifically, you seem
to be suggesting that a linear regression model could be used to
predict the mean end-to-end response time of an appstring by
considering the CPU utilizations of the critical path components as
the independent variables. Is this correct?
<br>
<br>
A couple of questions:
<br>
<br>
1) It is not clear in the slide what the independent variables really
are. Are the the software components specified worst case execution
time? The software component's measured mean execution time? The
utilization on the CPU that the application runs on?
<br>
<br>
2) The equation on slide 2 has one coefficient but slide 3 implies
there is a coefficient per CPU term. Which is correct?
<br>
<br>
3) You are estimating mean e2e times. Correct? Typically we are also
interested in worst case end to end times. Do you intend to consider
that problem as well?
<br>
<br>
Thanks,
<br>
<br>
Patrick
<br>
<br>
<br>
<br>
Alan F. Karr wrote:
<br>
<blockquote type="cite">Colleagues,
<br>
<br>
Here is some interesting evidence that the pieces of our tool chain are
actually links.
<br>
<br>
We took all configurations tested to date with 42, 43 or 44 processors
(As discussed yesterday, this is in some sense "where the action is")
and asked whether the /*model-derived*/ CPU utilizations along the
critical path predict the /*measured*/ end-to-end times, also along the
critical path. So far, the only models are considered are linear
regressions. The fits are quite remarkably good.
<br>
<br>
A PowerPoint file summarizing the results is attached. Comments and
reactions are welcome. I will attempt to put this on the wiki.
<br>
<br>
--- Alan
<br>
<br>
-- <br>
******************************************************************
<br>
* Alan F. Karr, Director * Tel: 919.685.9300 *
<br>
* National Institute of Statistical Sciences * FAX: 919.685.9310 *
<br>
* 19 T. W. Alexander Drive (FedEx/UPS) * <a class="moz-txt-link-abbreviated" href="mailto:karr@niss.org">karr@niss.org</a> *
<br>
* P.O. Box 14006 (USPS) * <a class="moz-txt-link-abbreviated" href="http://www.niss.org">www.niss.org</a> *
<br>
* Research Triangle Park, NC 27709-4006 * *
<br>
******************************************************************
<br>
------------------------------------------------------------------------
<br>
<br>
_______________________________________________
<br>
Cadynce mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Cadynce@list.isis.vanderbilt.edu">Cadynce@list.isis.vanderbilt.edu</a>
<br>
<a class="moz-txt-link-freetext" href="http://list.isis.vanderbilt.edu/mailman/listinfo/cadynce">http://list.isis.vanderbilt.edu/mailman/listinfo/cadynce</a>
<br>
</blockquote>
</blockquote>
<br>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
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>