Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #12821

Re: Resource revocation

Cross-posted to 2 groups.

Show all headers | View raw

Hi Richard,

On 7/28/2013 9:10 PM, Richard Damon wrote:

>> Real systems aren't binary like that.  Real systems expect some
>> number of HARD deadlines to be missed -- each with potentially
>> different costs/consequences/lost opportunities.

>>> I TOTALLY disagree, if you are contracted to provide a system to met a
>>> certain standard, and to met that standard you must hit a deadline, that
>>> deadline is a Hard Real Time deadline.
>>
>> You are confusing the system spec with the nature of the specific
>> task that has the deadline.  If your system has exactly one task
>> to perform, exactly once, and that task has a hard deadline (i.e.,
>> once the deadline has passed, you may as well pull the plug and
>> shut the equipment down), AND your SYSTEM SPEC is that you meet
>> all hard deadlines, then, missing that one deadline means your system
>> is crap.
>>
>> If your system, instead, has to perform that task 100 times -- each
>> time having an independent HARD deadline (i.e., a point in time
>> beyond which there is no remaining value to working on that particular
>> instance of that task) and the system spec says you must meet 50%
>> of these, then once you have completed 50 of the tasks successfully,
>> your *system* has met its specified requirement.

> As I said, I work with a different definition which considers Hard Real
> Time to be a system level definition. A Hard Real Time system is one
> that has a hard deadline that must be met ALWAYS.

No.  A Hard Real Time SYSTEM is one that must meet ALL of it's hard
deadlines.  Most non-trivial systems have more than one deadline/task.

> If I only need to met
> it 50% of the time, it isn't a Hard deadline, it is Soft. The difference
> being what type of design/analysis methods need to be used on the
> system. If I have 100 tasks, and one occasionally fails to met its
> deadline, and that deadline was hard, then the SYSTEM has failed, and
> doesn't meet its requirements.

Yes.  But only if one (or more) of the HRT tasks missed its deadline.
Calling a SYSTEM "hard" means very little.  It just says, "I am
brittle (and probably over-specified)"

By that definition, most systems are NOT "hard" because most systems
allow hard deadlines to be missed.

(This is the mistake many RT practitioners make:  treating everything
as a hard deadline -- even things that aren't inherently hard.  Then,
throwing resources at the system to try to meet all of these unnecessary
deadlines.)

> (This doesn't mean that you immediately
> take the system down, failed systems can still sometimes do useful
> work). If a system fails during qualification, then it will normally be
> brought back with orders to "Fix it". (It being the given unit if the
> problem is unique to it, the whole batch if you can't show why that one
> was different). If it fails after passing qualification, then that unit
> is normally returned to be fixed and if you can't show a specific error
> on that unit causing the problem, you pay fora fix for the whole product
> line.

This is why thinking about tasks (and systems) in terms of value
functions is so much more sensible.  It lets you (being the
developer *or* a scheduling algorithm!) decide how to deploy
resources based on the *value* of individual deadlines
(instead of trying to assign arbitrary "priorities" to tasks)
and hoping they get done in a timely fashion.  And, juggling the
priorities if they don't!

>>> The fact that there are
>>> mitigation options that reduce the damage from failure, does not convert
>>> the problem to a "soft" domain. To do so would mean you might try to
>>> apply the wrong tools to the problem.
>>
>> Again, damage is the wrong way of looking at it.  The issue is
>> the value of completing the task with respect to the deadline.
>> How you map that into dollars and the remedies into similar
>> dollars is a separate issue.
>>
>> It boils down to whether or not you should even *consider* working
>> on the problem after the deadline.  If the answer is an unconditional
>> "no" -- regardlesss of monies, costs, etc. -- then you have implicitly
>> said that there is no value to a late answer.
>>
>> OTOH, if you will consider continuing work on the task after
>> the deadline, then you are admitting there is still some potential
>> value to its completion and are willing to entertain a cost-benefit
>> analysis to determine how much effort/resources you are willing to
>> throw at the problem -- along with the possible repurcussions this
>> may have on other tasks remaining in the system.
>
> I would say that the value of work being done after the deadline is a
> very POOR indicator of how you should treat this deadline. By your
> definition you can have a lot of hard deadlines that don't really matter
> if you make them or not, they may provide "value" to the system by some
> measure, but don't really matter to the system meeting it critical
> performance requirements.

Exactly.  A hard deadline causes the developer, design, scheduler, etc.
to pay particular attention to some point in time and a workload
associated with it.  To dispatch resources to satisfy that deadline,
potentially at the cost of other "more important" (in the grand
scheme of things) tasks.  And, to feel free to STOP working on
towards that goal once the deadline has passed.  "Forget about it".

By contrast, a design/developer/scheduler has to constantly keep
juggling the "value" of SRT tasks to decide how best to deploy
the limited resources available.  But, in return, it keeps
*trying* to deploy resources (if it makes sense given other
deadlines/values) on that task long after the deadline has
passed.

E.g., using value/utility functions lets these agencies figure out
the "optimal" way to proceed towards satisfying all of their goals
(in the context of time).  I.e., maximize the "value".

>>> Hard Real Time systems need to be analyzed by guarantees. Can we PROVE
>>> that the deadlines WILL be met. This requires looking at total worse
>>> case paths. Any missing of the deadline is considered a failure. (So by
>>> the value function of success/failure, there is no value pass the
>>> deadline, but for other value functions, there may be).
>>
>> But you can tolerate failures!  Or, *systems* can be specified
>> to accept certain numbers and types of failures -- as per the
>> criteria set out by the system's specifications.
>
> Sometimes systems can be specified to accept certain levels of failures,
> but to me, if that level isn't virtually 0, then you don't have a real
> Hard Real Time system, but the system is really just a Soft Real Time
> system, as the difference between Hard and Soft is the acceptability of
> missing some deadlines.

No.  Missing a hard deadline can be acceptable (in a non HARD
*system*).  It boils down to the value of working on the task AFTER
the deadline has passed.  Hard deadlines can essentially disappear
once they have passed.  Kill off anything associated with that task;
its no longer needed.  (This is what I typically have my deadline
handler do -- kill all related processes and free all held resources
once the deadline is gone.)  You failed to intercept the incoming
missile before it reached its target.  That's unfortunate.  But, move
on to something *else*, now.  Something where you can "make a
difference"...

Your "system specification" typically describes what sort of
tolerance you have for particular deadlines and types of
deadlines being missed.  And, perhaps, how likely that may be.

If this criteria is "all hard deadlines must be met", then
the SYSTEM is HRT and *ALL* hard deadlines must be met -- even
if they are trivial ones (like illuminate the power indicator
within 2 seconds of the application of power).  There's no
"slack" (i.e., brittle)

This is why designing soft real-time systems is a much more
difficult problem.  Because there is no SIMPLE, cut and dry
criteria where you can say "it's broke".

"I need a faster processor/more memory/etc. because I can't
meet this hard deadline, otherwise."  (i.e., you end up
with overspecified hardware, usually -- since many apparently
hard deadlines can be redefined in a soft sense with some
careful thought)

>>> Soft Real Time system need to be analyzed on more general performance
>>> basis. Individual steps might not function totally right, but, perhaps
>>> due to fault tolerance, the final results is still "good".
>>>
>>> Going back to your pusher system, if the system was specified that it
>>> only needed to get 90% of the bottles off the belt, and that a few
>>> getting by were acceptable, then the problem, even though for a single
>>> event has 0 value on a miss, is a Soft Real Time System, as I no longer
>>> need to work on 100% guarantees, absolute worse case timings, etc, but
>>> on a more probabilistic model, needing statistical promises, not
>>> absolute.
>>
>> No.  It is still a hard deadline -- when the bottle hits the floor,
>> the deadline has passed.  It can be soft up to that point (as in
>> my "move the picker arm" example).
>>
>> If the arm can't move, then it's HRT.  You approach it *as* an HRT
>> problem.  You don't "hope" you get 90% of them -- if you run the
>> experiment indefinitely.
>>
>> The events are different from the system.  You apply different criteria
>> to the system's specification than to the specification for the
>> individual tasks that comprise it.
>>
>> Jensen's real-time.org should be required reading for anyone thinking
>> about RT work.  Unfortunately, much of it reads like a text book
>> but that sort of clinical presentation has a lot of value in nailing
>> down the edges of these issues!
>
> Taking a quick look at that site, He defines Hard / Soft deadlines as
> you seem to be refering to as Hard / Soft Real Time deadline. I do see a
> definition of a Hard Real Time System as: "A system having only actions
> with hard deadlines, and a sequencing goal of always meeting all those
> hard deadlines (i.e., deterministic maximum sequencing optimality), is a
> hard real-time system", which seems to fit with my definition. He uses
> real-time as a modifier for Systems and Actions, not deadlines (those
> are Hard or Soft).

      "A hard real-time system is one whose sequencing timeliness
      factors (there also may be non-timeliness factors) are:
      * optimality is the binary case that meeting all hard deadlines
        is optimal and otherwise is suboptimal (in some system-,
        application-, or situation-specific way)
      * predictability of optimality is deterministic."

Further:

      "It is relatively unusual for a computing system to be
      intrinsically hard real-time. Most non-trivial real-time
      systems have execution entities with a mixture of hard
      deadlines and softer time constraints, such as deadlines
      and the equivalent of time/utility functions (although not
      usually understood and expressed that explicitly), plus
      execution entities that have no time constraints (but are
      subject to non-timeliness sequencing factors). Hard real-time
      systems typically arise as follows:

      ...

      or all the time constraints are artificially forced to be
      hard deadlines because the system, or its designers/implementers
      /users, can’t deal with any other kind of time constraints."

(i.e., SRT is harder than HRT)  And, if you have a nontrivial RT,
chances are, it is NOT an HRT *SYSTEM*!  (think about it... everything
must be met?  Really??  Nothing can slip "just a little bit"?)

      "Forcing all time constraints to be hard deadlines often limits
      the system’s flexibility and adaptability, while increasing the
      hardware resource requirements and lowering the hardware resource
      efficiency."

As I said, "brittle"; "inefficient".

And:

      "It is clear that in the technical sense defined here (as opposed
      to popular misusage by practitioners), soft real-time systems are
      considerably more difficult to create than are hard real-time
      ones. Some of this disparity is the intrinsically greater
      complexity of soft real-time applications, systems, and execution
      environments. But some is only a transient artifact – both theory
      and practice of real-time computing systems have historically
      focused primarily on hard real-time, and that is necessarily
      changing."

--don

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Resource revocation Don Y <this@isnotme.com> - 2013-07-25 12:23 -0700
  Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-25 12:51 -0700
    Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-25 15:00 -0700
      Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-25 19:38 -0700
        Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-25 22:12 -0700
          Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-25 23:37 -0700
            Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 01:13 -0700
              Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 02:48 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 04:19 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 09:46 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 10:21 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 19:30 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 11:56 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 20:08 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 13:11 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 12:31 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 11:08 -0700
                Re: Resource revocation Rob Gaddi <rgaddi@technologyhighland.invalid> - 2013-07-29 09:16 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-29 10:22 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 11:22 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 08:56 -0700
                Re: Resource revocation Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-07-26 19:25 +0200
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 10:51 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 19:21 +0100
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 11:50 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 19:42 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 12:43 -0700
                Does the Buddha have a real time nature? ;)  (was Resource revocation) Roberto Waltman <usenet@rwaltman.com> - 2013-07-26 17:06 -0400
                Re: Does the Buddha have a real time nature? ;)  (was Resource revocation) Don Y <this@isnotme.com> - 2013-07-26 17:12 -0700
                Re: Does the Buddha have a real time nature? ;)  (was Resource revocation) Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 09:44 +0100
                Re: Does the Buddha have a real time nature? ;)  (was Resource revocation) Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 09:45 +0100
                Re: Does the Buddha have a real time nature? ;)  (was Resource revocation) Don Y <this@isnotme.com> - 2013-07-27 12:28 -0700
                Re: Does the Buddha have a real time nature? ;)  (was Resource revocation) Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-07-27 14:11 +0200
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 12:40 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 21:29 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 13:52 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 22:55 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 17:22 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 10:02 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 09:29 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 18:20 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 12:48 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 22:57 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 16:18 -0700
                Re: Resource revocation Roberto Waltman <usenet@rwaltman.com> - 2013-07-31 16:33 -0400
                Re: Resource revocation upsidedown@downunder.com - 2013-07-27 22:53 +0300
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 22:42 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 16:41 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 16:49 -0700
                Re: Resource revocation upsidedown@downunder.com - 2013-07-28 08:39 +0300
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 23:11 -0700
                Re: Resource revocation Roberto Waltman <usenet@rwaltman.com> - 2013-07-31 16:15 -0400
                Re: Resource revocation upsidedown@downunder.com - 2013-08-01 00:13 +0300
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 15:16 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 23:05 +0100
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 15:37 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 23:38 +0100
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 16:08 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-28 01:16 +0100
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 18:43 -0700
                Re: Resource revocation upsidedown@downunder.com - 2013-07-28 09:01 +0300
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 15:21 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 23:07 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 12:00 -0700
                Re: Resource revocation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-07-27 16:49 +0000
                Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-28 18:31 -0400
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-28 15:51 -0700
                Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-28 20:12 -0400
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-28 18:35 -0700
                Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-29 00:10 -0400
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 00:23 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-29 01:05 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 12:07 -0700
                Re: Resource revocation upsidedown@downunder.com - 2013-07-30 01:11 +0300
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 15:20 -0700
                Re: Resource revocation Rob Gaddi <rgaddi@technologyhighland.invalid> - 2013-07-29 15:42 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 16:41 -0700
                Re: Resource revocation upsidedown@downunder.com - 2013-07-30 08:51 +0300
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 09:09 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 01:30 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 10:04 +0100
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-30 02:55 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 07:12 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 16:59 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 13:17 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-30 10:12 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 18:48 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 20:18 -0700
                Re: Resource revocation upsidedown@downunder.com - 2013-07-31 09:27 +0300
                Re: Resource revocation [long] Don Y <this@isnotme.com> - 2013-07-31 00:47 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-30 02:50 -0700
                Re: Resource revocation upsidedown@downunder.com - 2013-07-30 13:22 +0300
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 07:24 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 01:17 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-29 19:28 -0700
                Re: Resource revocation upsidedown@downunder.com - 2013-07-29 11:40 +0300
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 11:44 -0700
                Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-29 20:56 +0100
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 13:16 -0700
                Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-30 00:08 -0400
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 23:41 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-31 00:58 -0700
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-31 10:18 -0700
                Re: Resource revocation George Neuner <gneuner2@comcast.net> - 2013-08-02 06:19 -0400
                Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-08-03 02:26 -0400
                Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-28 19:31 -0700
                Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 00:44 -0700
  Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-25 22:42 -0400
    Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-25 22:12 -0700
  Re: Resource revocation "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2013-07-31 13:41 +0200
    Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-31 07:51 -0700
      Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-31 08:07 -0700
        Re: Resource revocation Anders.Montonen@kapsi.spam.stop.fi.invalid - 2013-07-31 15:55 +0000
          Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-31 10:18 -0700
      Re: Resource revocation "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2013-08-01 14:42 +0200
        Re: Resource revocation Don Y <this@isnotme.com> - 2013-08-01 14:34 -0700
      Re: Resource revocation upsidedown@downunder.com - 2013-08-02 09:08 +0300
        Re: Resource revocation Don Y <this@isnotme.com> - 2013-08-02 07:26 -0700

csiph-web