1 |
momentics wrote: |
2 |
> That's nearly perfect James - a really quick overview on tons of papers. |
3 |
> Thanks. |
4 |
> |
5 |
> What do you think of probabilistic theory and system/OS controllable |
6 |
> scheduling of sequential/parallel execution (actually fault tolerant) |
7 |
> where instead of check pointing it relies on voting of SM responses, |
8 |
> where a whole application is divided on several |
9 |
> functionality-completed SMs; and missed deadlines of application parts |
10 |
> are just a subset of covered faults (most of its faulty semantic |
11 |
> hardened up to timing and/or crash failure semantics). |
12 |
> As a result, it achieves a predictable HRT with a given reliability |
13 |
|
14 |
|
15 |
Throwing 'slow curve_balls' at an old timer, is a dangerous affair, |
16 |
as you know.... |
17 |
|
18 |
|
19 |
voting is not new, only newly repackaged. Achievement of fault |
20 |
tolerance, is quite simple, when a fault occurs, your system continues |
21 |
to a valid conclusion. Whether you use check-pointing, roll back and |
22 |
recovery, voting, or some other methodology as the underlying |
23 |
mechanism, makes absolutely no difference to establishing the ability |
24 |
of a system to handle faults. (That's the slow part of your pitch you |
25 |
wanted me to take a swing at). |
26 |
|
27 |
Missed deadlines are exactly my thesis. Deadlines (timing constraints) |
28 |
are rarely anything but arbitrary. The fact that |
29 |
one can 'massage' a number as in the example of my previous |
30 |
posting on the missile rudder, is one case. What determines or |
31 |
establishes timing of one component in an overall system? And if you |
32 |
miss it by a very small margin, but consistently miss it by that very |
33 |
small margin, then, if you redefine your requirement, it moves from |
34 |
soft to hard characterization. That my friend is the exact reason why |
35 |
there really is no such thing as 'hard real time'. It's sheer |
36 |
conjecture and folly. You can take a soft real time system and define |
37 |
your measurement stick a little bit more loosely, and end up with hard |
38 |
real time. |
39 |
|
40 |
Furthermore, there is absolutely no difference in a deterministic |
41 |
system and a fully deterministic system, except the latter reminds |
42 |
us how difficult or impossible determinism actually is. |
43 |
|
44 |
Your HRT system you define above is more correctly described |
45 |
as a reliable, low latency system with tight timing constraints. |
46 |
Soft and Hard real time, although used commonly by very well educated |
47 |
persons, are actually mathematically imprecise. But when a manager |
48 |
or sales-lizard or MBA heres those terms they go wild with excitement |
49 |
and get folks with a checkbook to get excited and spend money. |
50 |
That's the allure of the entire soft vs hard real time bonanza! |
51 |
It does not matter that those folks with checkbooks actually work |
52 |
at the NSF, DOD or European Space Agency, and may have even |
53 |
been good engineers or scientist at one time. |
54 |
|
55 |
You can actually define a state machine with hard real time, on any |
56 |
subset or the entire system, but you have to go through extensive |
57 |
testing to establish it, mathematically. And when a pre-conditioned |
58 |
'hard real time' goal is absolutely unattainable by the most gifted |
59 |
(savant) firmware programmer and that person is not speaking to the |
60 |
hardware engineers at the silicon vendor's fab, you lower |
61 |
expectations, bless the system as HRT and go to press with the |
62 |
sales campaign. |
63 |
|
64 |
(so did I hit the curve, or do you have a 'drop' component |
65 |
to your slow curve?). |
66 |
|
67 |
|
68 |
James |
69 |
|
70 |
|
71 |
|
72 |
|
73 |
|
74 |
|
75 |
-- |
76 |
gentoo-embedded@g.o mailing list |