My fault for not having explained. Let me see if I can clarify. Let's
just consider the simple case in which application instances do not
enqueue (i.e., as soon as the application detects to have missed a
deadline, it discards the current job, as opposed to keep computing the
current job), and consider a reservation period == application period.
In such a case, if 'C' represents the (probabilistically modeled)
computation time of a job, then:
Prob{deadline hit} = Prob{enough runtime for a job instance} = Prob{C
<= runtime}.
So, if runtime is set as the q-th quantile of the `C' probability
distribution, then:
Prob{deadline hit} = Prob{C <= runtime} = q
This is true independently of what else is admitted into the system, as
far as I get my runtime guaranteed from the scheduler.
Does this now make sense ?
If, on the other hand, task instances enqueue (e.g., I keep decoding the
current frame even if I know a new frame arrived), then the probability
of deadline-hit will be lower than q, and generally speaking one can use
stochastic analysis & queueing theory techniques in order to figure out
what it actually is.
Here I was not referring to GEDF, but simply to the case in which we are
reserved from the kernel a budget every period (whatever the scheduling
algorithm): as the reserved budget moves from the WCET down towards the
average computation time, the response time distribution moves from a
shape entirely contained below the deadline, to a more and more flat
shape, where the probability of missing the deadline for the task
increases over and over. Roughly speaking, if the application instances
do not enqueue, then with a budget = average computation time, I would
expect a ~50% deadline miss, something which hardly is acceptable even
for soft RT applications.
If instances instead enqueue, then the situation may go much worse,
because the response-time distribution flattens with a long tail beyond
the deadline. The maximum value of it approaches +\infty with the
reserved budget approaching the average computation time.
I'd need some more explanation, sorry, I couldn't understand what you're
proposing.
I was assuming you were proposing to keep an admission test based on
providing the parameters needed for checking whether or not a given
tardiness bound were respected. I must have misunderstood. Would you
please detail what is the test (and result in the paper) you are
thinking of using ?
Sure, I agree. I was simply suggesting it as a last-resort option
(possibly usable by exploiting a compile-time option of the scheduler
compiling out the admission test), useful in those cases in which you do
have a user-space complex admission test that you made (or even an
off-line static analysis of your system) but the simple admission test
into the kernel would actually reject the task set, being the test
merely sufficient.
Bye,
T.
--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso
--
