Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.realtime > #174 > unrolled thread
| Started by | Don Y <this@isnotme.com> |
|---|---|
| First post | 2013-07-25 12:23 -0700 |
| Last post | 2013-08-02 07:26 -0700 |
| Articles | 20 on this page of 73 — 12 participants |
Back to article view | Back to comp.realtime
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 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
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: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: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
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2013-07-28 18:31 -0400 |
| Message-ID | <nZgJt.598074$%p1.173951@en-nntp-02.dc1.easynews.com> |
| In reply to | #187 |
On 7/26/13 1:25 PM, Hans-Bernhard Bröker wrote: > On 26.07.2013 11:48, Paul Rubin wrote: >> Don Y <this@isnotme.com> writes: > >> Hard deadlines in realtime programming usually mean microseconds or so. >> This plant watering stuff isn't even soft realtime (where you generally >> want responses within milliseconds but are allowed to miss >> occasionally). > > This is a very common misconception, but still just as wrong. Realtime > has nothing to do whatsoever with the length of any particular interval > of time. It doesn't matter if your deadline is coming every 50 > nanoseconds or once a year. If there's a deadline, and it's defined as > a point fixed in time, then you're doing realtime processing. > > Nor is the distinction between soft and hard realtime to be found in the > timescales involved, but in the gravity of consequences if you miss a > deadline. > > In other words, realtime is about whether there _is_ a "too late", not > _when_ that might be. > I use a different definition of Hard/Soft Real time. Hard Real Time is the domain of timing specifications that missing is considered a FAILURE of the system, it hasn't met specifications, and the "customer" gets to blame us for the problem. Of course if the input to the system aren't within specifications, we can push the blame back to the input. A Soft Real Time specification allows for the missing of some deadlines, but there is some overall level of performance that must be met, which is hurt by missing the deadline. There may well be a LOT of value to still completing the task after the deadline, but at that point you are in the domain of "damage control" to minimize level of failure. (Maybe you only maim someone instead of kill them). Looking at the example of the rocket burn, a late burn likely is considered a failure, but a late burn may let you make another correction to get back on course. You likely have now used more fuel than planned, so something in the mission will need to be changed. This is a lot less damaging than saying that we missed the burn so we might as well just scrap the whole missing and let the craft hurl into space.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-28 15:51 -0700 |
| Message-ID | <kt47a7$505$1@speranza.aioe.org> |
| In reply to | #196 |
Hi Richard, On 7/28/2013 3:31 PM, Richard Damon wrote: [attributions elided] >>> Hard deadlines in realtime programming usually mean microseconds or so. >>> This plant watering stuff isn't even soft realtime (where you generally >>> want responses within milliseconds but are allowed to miss >>> occasionally). >> >> This is a very common misconception, but still just as wrong. Realtime >> has nothing to do whatsoever with the length of any particular interval >> of time. It doesn't matter if your deadline is coming every 50 >> nanoseconds or once a year. If there's a deadline, and it's defined as >> a point fixed in time, then you're doing realtime processing. >> >> Nor is the distinction between soft and hard realtime to be found in the >> timescales involved, but in the gravity of consequences if you miss a >> deadline. >> >> In other words, realtime is about whether there _is_ a "too late", not >> _when_ that might be. > > I use a different definition of Hard/Soft Real time. Hard Real Time is > the domain of timing specifications that missing is considered a FAILURE > of the system, it hasn't met specifications, and the "customer" gets to > blame us for the problem. Of course if the input to the system aren't > within specifications, we can push the blame back to the input. > > A Soft Real Time specification allows for the missing of some deadlines, > but there is some overall level of performance that must be met, which > is hurt by missing the deadline. Note that the system can still meet its objectives, late (see below). It's just that it would be "worth more" if they had been met "on time". (i.e., perhaps COST LESS to implement) > There may well be a LOT of value to still completing the task after the > deadline, If there is *any* value after the deadline, then it is not HRT. HRT is defined as *no* value after the deadline (including possibly "negative value") > but at that point you are in the domain of "damage control" to > minimize level of failure. Note that there might not be any damage done -- even after the deadline! It may simply reflect the fact that it will COST more to complete the task after the deadline. E.g., if you are picking items off a moving conveyor, picking it *at* a certain point is preferable -- because the picking arm idles at that location! But, if you are late getting the item, you might still be able to reposition the arm (via a servo) to grab the item at some point *past* the ideal location. It obviously costs more to do so. (energy to move the mechanism, increased probability that you might not be able to get the *next* item correctly, etc.) But, until the item moves to a point beyond which the actuator can seize it, there is still value (decreasing) to your attempts to grab it! > (Maybe you only maim someone instead of kill them). While I understand the point you are trying to make by this example, I try to avoid them because it tends to conflate "safety" and timeliness. People end up thinking "if someone is going to die" then it's HRT! E.g., smoking cessation has value regardless (?) of when it happens. But, obviously MORE value "early" than "late" (where "early" and "late" are subjective terms) > Looking at the example of the rocket burn, a late burn likely is > considered a failure, but a late burn may let you make another > correction to get back on course. You likely have now used more fuel > than planned, so something in the mission will need to be changed. This > is a lot less damaging than saying that we missed the burn so we might > as well just scrap the whole missing and let the craft hurl into space. The two examples, here, differ in that one is HRT and the other SRT. If missing the deadline means there is no value to continuing to "work on the problem", then its HRT. The only result is hurtling into space. OTOH, if there is some value to continuing to work on it (because orbital insertion despite the loss of some *other* mission feature is better -- more valuable -- than scrapping the mission entirely), then it is SRT. Note that almost always there is some *hard* deadline beyond which a solution to an SRT problem becomes moot.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2013-07-28 20:12 -0400 |
| Message-ID | <_riJt.598075$%p1.483412@en-nntp-02.dc1.easynews.com> |
| In reply to | #197 |
On 7/28/13 6:51 PM, Don Y wrote: > Hi Richard, > > On 7/28/2013 3:31 PM, Richard Damon wrote: > > [attributions elided] > >>>> Hard deadlines in realtime programming usually mean microseconds or so. >>>> This plant watering stuff isn't even soft realtime (where you generally >>>> want responses within milliseconds but are allowed to miss >>>> occasionally). >>> >>> This is a very common misconception, but still just as wrong. Realtime >>> has nothing to do whatsoever with the length of any particular interval >>> of time. It doesn't matter if your deadline is coming every 50 >>> nanoseconds or once a year. If there's a deadline, and it's defined as >>> a point fixed in time, then you're doing realtime processing. >>> >>> Nor is the distinction between soft and hard realtime to be found in the >>> timescales involved, but in the gravity of consequences if you miss a >>> deadline. >>> >>> In other words, realtime is about whether there _is_ a "too late", not >>> _when_ that might be. >> >> I use a different definition of Hard/Soft Real time. Hard Real Time is >> the domain of timing specifications that missing is considered a FAILURE >> of the system, it hasn't met specifications, and the "customer" gets to >> blame us for the problem. Of course if the input to the system aren't >> within specifications, we can push the blame back to the input. >> >> A Soft Real Time specification allows for the missing of some deadlines, >> but there is some overall level of performance that must be met, which >> is hurt by missing the deadline. > > Note that the system can still meet its objectives, late (see below). > It's just that it would be "worth more" if they had been met "on time". > (i.e., perhaps COST LESS to implement) > >> There may well be a LOT of value to still completing the task after the >> deadline, > > If there is *any* value after the deadline, then it is not HRT. > HRT is defined as *no* value after the deadline (including possibly > "negative value") > >> but at that point you are in the domain of "damage control" to >> minimize level of failure. > > Note that there might not be any damage done -- even after the deadline! > It may simply reflect the fact that it will COST more to complete the > task after the deadline. > > E.g., if you are picking items off a moving conveyor, picking it > *at* a certain point is preferable -- because the picking arm > idles at that location! > > But, if you are late getting the item, you might still be able to > reposition the arm (via a servo) to grab the item at some point > *past* the ideal location. It obviously costs more to do so. > (energy to move the mechanism, increased probability that you > might not be able to get the *next* item correctly, etc.) > But, until the item moves to a point beyond which the actuator > can seize it, there is still value (decreasing) to your attempts > to grab it! This is a difference in an event view and a systems view. In your view, a system that is 90% successful at picking off the boxes is worth 90% of full value. In my view, if the system had a true Hard Real Time spec here, anything less than 100% success is a system failure, and unless the system was speced to allow less than 100% reliability, it is a FAILURE, and the customer is in there rights to request a refund or insist that the unit be fixed to work within spec. > >> (Maybe you only maim someone instead of kill them). > > While I understand the point you are trying to make by this > example, I try to avoid them because it tends to conflate "safety" > and timeliness. People end up thinking "if someone is going to die" > then it's HRT! > I agree that not all safety issues are based on HRT. But this also doesn't make the fact that being just slightly late causes a lot less of a "disaster" then being really late make the event a not Hard Real Time event. If being 1 ms late means it costs you $1000, but 1 s late cost you $1,000,000, there is REAL value after the deadline to complete, but it doesn't mean the deadline was "soft". > E.g., smoking cessation has value regardless (?) of when it > happens. But, obviously MORE value "early" than "late" (where > "early" and "late" are subjective terms) > >> Looking at the example of the rocket burn, a late burn likely is >> considered a failure, but a late burn may let you make another >> correction to get back on course. You likely have now used more fuel >> than planned, so something in the mission will need to be changed. This >> is a lot less damaging than saying that we missed the burn so we might >> as well just scrap the whole missing and let the craft hurl into space. > > The two examples, here, differ in that one is HRT and the other SRT. > If missing the deadline means there is no value to continuing to > "work on the problem", then its HRT. The only result is hurtling into > space. > > OTOH, if there is some value to continuing to work on it (because > orbital insertion despite the loss of some *other* mission feature > is better -- more valuable -- than scrapping the mission entirely), > then it is SRT. 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. 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. 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). 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. > > Note that almost always there is some *hard* deadline beyond which > a solution to an SRT problem becomes moot.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-28 18:35 -0700 |
| Message-ID | <kt4gtl$q0g$1@speranza.aioe.org> |
| In reply to | #198 |
Hi Richard,
On 7/28/2013 5:12 PM, Richard Damon wrote:
> On 7/28/13 6:51 PM, Don Y wrote:
>> But, if you are late getting the item, you might still be able to
>> reposition the arm (via a servo) to grab the item at some point
>> *past* the ideal location. It obviously costs more to do so.
>> (energy to move the mechanism, increased probability that you
>> might not be able to get the *next* item correctly, etc.)
>> But, until the item moves to a point beyond which the actuator
>> can seize it, there is still value (decreasing) to your attempts
>> to grab it!
>
> This is a difference in an event view and a systems view. In your view,
> a system that is 90% successful at picking off the boxes is worth 90% of
> full value.
No. You deal with the events as events. How you decide if the
*system* has failed is subject to other criteria -- unrelated to
HARD or SOFT.
E.g., if you don't intercept an incoming missile before it
reaches its target (hard deadline), *that* task has failed.
It's not worth continuing to track and target the missile
as it plows into the ground. Abandon that task. (you may
have learned something from the effort that can be applied to
tracking *otehr* missiles; or, you may not. In any case,
*that* missile is a done deal!)
Whether missing that HARD deadline has resulted in your *system*
being considered a failure is a different issue. Should you throw
your hands up in the air and let any additional missiles come through
uncontested? What if that *one* had successfully targeted your
defensive battery? etc.
I.e., how you evaluate the system is dictated by a different set
of criteria.
> In my view, if the system had a true Hard Real Time spec here, anything
> less than 100% success is a system failure, and unless the system was
> speced to allow less than 100% reliability, it is a FAILURE, and the
> customer is in there rights to request a refund or insist that the unit
> be fixed to work within spec.
So, when the first SCUD got through the Patriot defenses, they
should have shut down the rest of the system and started bickering
over refunds??
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.
>>> (Maybe you only maim someone instead of kill them).
>>
>> While I understand the point you are trying to make by this
>> example, I try to avoid them because it tends to conflate "safety"
>> and timeliness. People end up thinking "if someone is going to die"
>> then it's HRT!
>
> I agree that not all safety issues are based on HRT. But this also
> doesn't make the fact that being just slightly late causes a lot less of
> a "disaster" then being really late make the event a not Hard Real Time
> event. If being 1 ms late means it costs you $1000, but 1 s late cost
> you $1,000,000, there is REAL value after the deadline to complete, but
> it doesn't mean the deadline was "soft".
No, it *does* mean the deadline was soft (if you consider "cost"
as "negative value"). That is the nature of the distinction.
HARD means you GIVE UP at 0.00000001ms after the deadline has
passed. You missed it. THERE IS NO VALUE TO CONTINUING.
[But, the consequences of that missed deadline may range from NOTHING
to THE END OF ALL LIFE AS WE KNOW IT. :> E.g., I have a deadline
handler in my RTOS that is triggered when a task fails to meet
its deadline. What the handler for a specific task might do can
vary from incrementing a metric to invoking a scheduling optimizer
that sheds some load to ensure future deadlines aren't missed]
By contrast, soft means you still have value to pursuing the goal.
I.e., given infinite resources, you would give up on a missed
HRT deadline but continue working on a missed SRT deadline.
Deciding when you might want to give up on the missed SRT deadline
is a complicated issue, in most cases. Resources spent pursuing that
goal detract from other goals being met. What value do you gain
(over time) vs. the costs/risks you incur? When do you decide
that the "expected value" of your gains is zero?
This is why SRT is "harder" than HRT. And, why SRT problems are
most often CONVERTED to HRT problems -- because they make this
decision making much easier! ("Once I am 12.3ms late on this
task, I will abandon it -- AS IF it was an HRT task!") I.e.,
deliberately "failing", by choice (since that, presumably,
allows the overall "value" of the system to be maximized)
>> E.g., smoking cessation has value regardless (?) of when it
>> happens. But, obviously MORE value "early" than "late" (where
>> "early" and "late" are subjective terms)
>>
>>> Looking at the example of the rocket burn, a late burn likely is
>>> considered a failure, but a late burn may let you make another
>>> correction to get back on course. You likely have now used more fuel
>>> than planned, so something in the mission will need to be changed. This
>>> is a lot less damaging than saying that we missed the burn so we might
>>> as well just scrap the whole missing and let the craft hurl into space.
>>
>> The two examples, here, differ in that one is HRT and the other SRT.
>> If missing the deadline means there is no value to continuing to
>> "work on the problem", then its HRT. The only result is hurtling into
>> space.
>>
>> OTOH, if there is some value to continuing to work on it (because
>> orbital insertion despite the loss of some *other* mission feature
>> is better -- more valuable -- than scrapping the mission entirely),
>> then it is SRT.
>
> 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.
The system spec is not the same as the definition of the requirements
for the individual tasks. (if there are 100 such tasks, what is *THE*
deadline? I need *one* number since you can't have more than one
deadline for *a* task!)
> 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.
> 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.
The same sort of argument applies to SRT deadlines being missed.
How much effort you expend trying to chase them down *after*
they have passed is a judgement call that you evaluate in the
context of the system specification.
> 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!
>> Note that almost always there is some *hard* deadline beyond which
>> a solution to an SRT problem becomes moot.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2013-07-29 00:10 -0400 |
| Message-ID | <HWlJt.4$nK2.2@en-nntp-11.dc1.easynews.com> |
| In reply to | #199 |
On 7/28/13 9:35 PM, Don Y wrote:
> Hi Richard,
>
> On 7/28/2013 5:12 PM, Richard Damon wrote:
>> On 7/28/13 6:51 PM, Don Y wrote:
>
>>> But, if you are late getting the item, you might still be able to
>>> reposition the arm (via a servo) to grab the item at some point
>>> *past* the ideal location. It obviously costs more to do so.
>>> (energy to move the mechanism, increased probability that you
>>> might not be able to get the *next* item correctly, etc.)
>>> But, until the item moves to a point beyond which the actuator
>>> can seize it, there is still value (decreasing) to your attempts
>>> to grab it!
>>
>> This is a difference in an event view and a systems view. In your view,
>> a system that is 90% successful at picking off the boxes is worth 90% of
>> full value.
>
> No. You deal with the events as events. How you decide if the
> *system* has failed is subject to other criteria -- unrelated to
> HARD or SOFT.
>
> E.g., if you don't intercept an incoming missile before it
> reaches its target (hard deadline), *that* task has failed.
> It's not worth continuing to track and target the missile
> as it plows into the ground. Abandon that task. (you may
> have learned something from the effort that can be applied to
> tracking *otehr* missiles; or, you may not. In any case,
> *that* missile is a done deal!)
>
> Whether missing that HARD deadline has resulted in your *system*
> being considered a failure is a different issue. Should you throw
> your hands up in the air and let any additional missiles come through
> uncontested? What if that *one* had successfully targeted your
> defensive battery? etc.
>
> I.e., how you evaluate the system is dictated by a different set
> of criteria.
>
>> In my view, if the system had a true Hard Real Time spec here, anything
>> less than 100% success is a system failure, and unless the system was
>> speced to allow less than 100% reliability, it is a FAILURE, and the
>> customer is in there rights to request a refund or insist that the unit
>> be fixed to work within spec.
>
> So, when the first SCUD got through the Patriot defenses, they
> should have shut down the rest of the system and started bickering
> over refunds??
>
> 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.
>
>>>> (Maybe you only maim someone instead of kill them).
>>>
>>> While I understand the point you are trying to make by this
>>> example, I try to avoid them because it tends to conflate "safety"
>>> and timeliness. People end up thinking "if someone is going to die"
>>> then it's HRT!
>>
>> I agree that not all safety issues are based on HRT. But this also
>> doesn't make the fact that being just slightly late causes a lot less of
>> a "disaster" then being really late make the event a not Hard Real Time
>> event. If being 1 ms late means it costs you $1000, but 1 s late cost
>> you $1,000,000, there is REAL value after the deadline to complete, but
>> it doesn't mean the deadline was "soft".
>
> No, it *does* mean the deadline was soft (if you consider "cost"
> as "negative value"). That is the nature of the distinction.
> HARD means you GIVE UP at 0.00000001ms after the deadline has
> passed. You missed it. THERE IS NO VALUE TO CONTINUING.
>
> [But, the consequences of that missed deadline may range from NOTHING
> to THE END OF ALL LIFE AS WE KNOW IT. :> E.g., I have a deadline
> handler in my RTOS that is triggered when a task fails to meet
> its deadline. What the handler for a specific task might do can
> vary from incrementing a metric to invoking a scheduling optimizer
> that sheds some load to ensure future deadlines aren't missed]
>
> By contrast, soft means you still have value to pursuing the goal.
> I.e., given infinite resources, you would give up on a missed
> HRT deadline but continue working on a missed SRT deadline.
>
> Deciding when you might want to give up on the missed SRT deadline
> is a complicated issue, in most cases. Resources spent pursuing that
> goal detract from other goals being met. What value do you gain
> (over time) vs. the costs/risks you incur? When do you decide
> that the "expected value" of your gains is zero?
>
> This is why SRT is "harder" than HRT. And, why SRT problems are
> most often CONVERTED to HRT problems -- because they make this
> decision making much easier! ("Once I am 12.3ms late on this
> task, I will abandon it -- AS IF it was an HRT task!") I.e.,
> deliberately "failing", by choice (since that, presumably,
> allows the overall "value" of the system to be maximized)
>
>>> E.g., smoking cessation has value regardless (?) of when it
>>> happens. But, obviously MORE value "early" than "late" (where
>>> "early" and "late" are subjective terms)
>>>
>>>> Looking at the example of the rocket burn, a late burn likely is
>>>> considered a failure, but a late burn may let you make another
>>>> correction to get back on course. You likely have now used more fuel
>>>> than planned, so something in the mission will need to be changed. This
>>>> is a lot less damaging than saying that we missed the burn so we might
>>>> as well just scrap the whole missing and let the craft hurl into space.
>>>
>>> The two examples, here, differ in that one is HRT and the other SRT.
>>> If missing the deadline means there is no value to continuing to
>>> "work on the problem", then its HRT. The only result is hurtling into
>>> space.
>>>
>>> OTOH, if there is some value to continuing to work on it (because
>>> orbital insertion despite the loss of some *other* mission feature
>>> is better -- more valuable -- than scrapping the mission entirely),
>>> then it is SRT.
>>
>> 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.
>
> The system spec is not the same as the definition of the requirements
> for the individual tasks. (if there are 100 such tasks, what is *THE*
> deadline? I need *one* number since you can't have more than one
> deadline for *a* task!)
>
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. 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. (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.
>> 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.
>
>> 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.
>
> The same sort of argument applies to SRT deadlines being missed.
> How much effort you expend trying to chase them down *after*
> they have passed is a judgement call that you evaluate in the
> context of the system specification.
>
>> 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).
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-29 00:23 -0700 |
| Message-ID | <kt559c$6s7$1@speranza.aioe.org> |
| In reply to | #201 |
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
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-29 01:05 -0700 |
| Message-ID | <7xfvuxx02j.fsf@ruckus.brouhaha.com> |
| In reply to | #202 |
Don Y <this@isnotme.com> writes: > And: > "It is clear that in the technical sense defined here (as opposed > to popular misusage by practitioners), The author is admitting above to peddling an idiosyncratic concept that doesn't match the usage of working practitioners in the real world. Therefore I don't feel compelled to treat it as gospel. > soft real-time systems are considerably more difficult to create > than are hard real-time ones. That's just plain silly. There are all kinds of random timing variations in a conventional computer system, due to cache memory, rotating disk drives, input data distributions (think of algorithms like hash tables with bad worst-case complexity), background servics contending for system resources, etc. In an SRT system with some specifications on the inputs, you can estimate or measure the distribution of those timing variations, run some tests to make sure stuff appears to work as expected, and you're done. You don't have to worry about rare outliers causing timing misses, since by definition occasional misses are acceptable. HRT requires sharp bounds on every operation and (in practice) normally very short deadlines, which impose a lot of constraints on the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-29 12:07 -0700 |
| Message-ID | <kt6ei0$2he$1@speranza.aioe.org> |
| In reply to | #204 |
Hi Paul,
On 7/29/2013 1:05 AM, Paul Rubin wrote:
> Don Y <this@isnotme.com> writes:
>> And:
>> "It is clear that in the technical sense defined here (as opposed
>> to popular misusage by practitioners),
>
> The author is admitting above to peddling an idiosyncratic concept that
> doesn't match the usage of working practitioners in the real world.
> Therefore I don't feel compelled to treat it as gospel.
You might want to read his entire treatise, carefully (i.e., as
if you were trying to LEARN it) and then examine his pedigree
before dismissing his (well thought out) argument.
>> soft real-time systems are considerably more difficult to create
>> than are hard real-time ones.
>
> That's just plain silly. There are all kinds of random timing
> variations in a conventional computer system, due to cache memory,
> rotating disk drives, input data distributions (think of algorithms like
> hash tables with bad worst-case complexity), background servics
> contending for system resources, etc.
Sure! But many of these the RT developer implements deterministically
instead of relying on some generic implementation NOT suited to RT.
> In an SRT system with some
> specifications on the inputs, you can estimate or measure the
> distribution of those timing variations, run some tests to make sure
> stuff appears to work as expected, and you're done. You don't have to
> worry about rare outliers causing timing misses, since by definition
> occasional misses are acceptable.
You're leaving performance entirely to chance. Making no attempt
to maximize it! "Oh, well... technically this task could be
6 hours late in meeting it's deadline... <shrug>"
> HRT requires sharp bounds on every
> operation and (in practice) normally very short deadlines, which impose
> a lot of constraints on the implementation.
Yeah, but the approach you described is exactly how you tackle
HRT! You figure out what its worst case performance characteristics
are -- then specify hardware/resources that will PROVIDE that level
of service: "The system NEEDS it!". Done.
You end up with more resources than you need because you have been
*forced* to expect everything to go wrong. (as an *informal*
testament of this, look at the maximum utilization for the rate
monotonic algorithm which GUARANTEES schedulabilty -- roughly 50%
excess capacity "just in case")
With SRT, you (assuming your goal is to provide the best possible
performance and not just "hey, it sorta works") have to evaluate
your options at each step. All eligible tasks have to be considered
regardless of the value of their utility functions AT THIS INSTANT
IN TIME. You can't dismiss tasks (HRT) whose deadlines have
passed because there still is tangible value in meeting those
goals. You don't just pick any task and let it run KNOWING
that it may make some other task late ("What the heck, that
task's deadline is soft so it *can* be late -- even if a better
scheduling choice could have caused it to NOT be late!")
Why not just schedule the remaining SRT tasks in ALPHABETICAL
ORDER? What the heck! Some WILL probably end up late but
they shouldn't care, right??
Think about it. It *should* be obvious!
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-07-30 01:11 +0300 |
| Message-ID | <1kodv8ldd1jarb6pofo53ev1j1jhtlb58k@4ax.com> |
| In reply to | #207 |
On Mon, 29 Jul 2013 12:07:43 -0700, Don Y <this@isnotme.com> wrote: >> HRT requires sharp bounds on every >> operation and (in practice) normally very short deadlines, which impose >> a lot of constraints on the implementation. > >Yeah, but the approach you described is exactly how you tackle >HRT! You figure out what its worst case performance characteristics >are -- then specify hardware/resources that will PROVIDE that level >of service: "The system NEEDS it!". Done. > >You end up with more resources than you need because you have been >*forced* to expect everything to go wrong. (as an *informal* >testament of this, look at the maximum utilization for the rate >monotonic algorithm which GUARANTEES schedulabilty -- roughly 50% >excess capacity "just in case") Excuse me, but what is the problem with 50 % excess capacity, i.e. 66 % CPU utilization. That is a pretty good figure, I would be quite happy with 50 % CPU utilization :-) PDP-11/RSX-11 was a quite good RT platforms to 60-70 % CPU load and Windows/Linux up to 40-50 % CPU load. I do not know if the rule of nines has been used in SRT discussions, but at least in telecommunication two nines imply 99 % reliability, three nines imply 99.9 % reliability and so on. In telecommunication, adding one niner requires transmitter power or antenna area and hence costs multiplied by 10. In a correctly configured Windows/Linux systems, getting three or four niners reliability is not that hard at 10 ms.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-29 15:20 -0700 |
| Message-ID | <kt6ps2$2e1$2@speranza.aioe.org> |
| In reply to | #210 |
On 7/29/2013 3:11 PM, upsidedown@downunder.com wrote: > On Mon, 29 Jul 2013 12:07:43 -0700, Don Y <this@isnotme.com> wrote: > >>> HRT requires sharp bounds on every >>> operation and (in practice) normally very short deadlines, which impose >>> a lot of constraints on the implementation. >> >> Yeah, but the approach you described is exactly how you tackle >> HRT! You figure out what its worst case performance characteristics >> are -- then specify hardware/resources that will PROVIDE that level >> of service: "The system NEEDS it!". Done. >> >> You end up with more resources than you need because you have been >> *forced* to expect everything to go wrong. (as an *informal* >> testament of this, look at the maximum utilization for the rate >> monotonic algorithm which GUARANTEES schedulabilty -- roughly 50% >> excess capacity "just in case") > > Excuse me, but what is the problem with 50 % excess capacity, i.e. 66 > % CPU utilization. > > That is a pretty good figure, I would be quite happy with 50 % CPU > utilization :-) But there are other scheduling algorithms that approach 100%! If you are building something that you intend to sell, excess capacity is wasted capacity is lost profit (or, increased price). (C.A.E has concerns other than getting something to work on a Linux desktop machine!) > PDP-11/RSX-11 was a quite good RT platforms to 60-70 % CPU load and > Windows/Linux up to 40-50 % CPU load. > > I do not know if the rule of nines has been used in SRT discussions, > but at least in telecommunication two nines imply 99 % reliability, > three nines imply 99.9 % reliability and so on. In telecommunication, > adding one niner requires transmitter power or antenna area and hence > costs multiplied by 10. > > In a correctly configured Windows/Linux systems, getting three or > four niners reliability is not that hard at 10 ms.
[toc] | [prev] | [next] | [standalone]
| From | Rob Gaddi <rgaddi@technologyhighland.invalid> |
|---|---|
| Date | 2013-07-29 15:42 -0700 |
| Message-ID | <20130729154258.6db874cb@rg.highlandtechnology.com> |
| In reply to | #211 |
On Mon, 29 Jul 2013 15:20:45 -0700 Don Y <this@isnotme.com> wrote: > On 7/29/2013 3:11 PM, upsidedown@downunder.com wrote: > > > That is a pretty good figure, I would be quite happy with 50 % CPU > > utilization :-) > > But there are other scheduling algorithms that approach 100%! > If you are building something that you intend to sell, excess > capacity is wasted capacity is lost profit (or, increased price). > Now THERE's a statement that's true when it's true and not when it's not. Let's say that for $0.25 a processor more I can shave two weeks of finagling with optimization. In a world with $1 Cortex M0 processors, that number is if anything high, it's probably closer to $0.10. Assume two weeks of my time plus two weeks earlier to market is worth $4K. I can sell 16,000 pieces before I make up that two week difference. For a lot of applications, preposterously cheap horsepower has outstripped our ability to use it all up. Failing to pay attention to that fact is like pretending you can still only get a forward beta of 50. Times change, parts improve, engineers still need sleep every now and again. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-29 16:41 -0700 |
| Message-ID | <kt6ujg$eci$1@speranza.aioe.org> |
| In reply to | #212 |
Hi Rob, On 7/29/2013 3:42 PM, Rob Gaddi wrote: > On Mon, 29 Jul 2013 15:20:45 -0700 > Don Y <this@isnotme.com> wrote: > >> On 7/29/2013 3:11 PM, upsidedown@downunder.com wrote: >> >>> That is a pretty good figure, I would be quite happy with 50 % CPU >>> utilization :-) >> >> But there are other scheduling algorithms that approach 100%! >> If you are building something that you intend to sell, excess >> capacity is wasted capacity is lost profit (or, increased price). > > Now THERE's a statement that's true when it's true and not when it's > not. Let's say that for $0.25 a processor more I can shave two weeks of > finagling with optimization. In a world with $1 Cortex M0 > processors, that number is if anything high, it's probably closer to > $0.10. > > Assume two weeks of my time plus two weeks earlier to market is worth > $4K. I can sell 16,000 pieces before I make up that two week > difference. You are thinking in small numbers! How many refrigerators do you think *one* manufacturer sells IN A YEAR (forget about next year)? How many irrigation controllers? Televisions? Dishwashers? etc. I've worked in industries where the saying was "you're paying for the plastic" (that the device is encapsulated in). You still find single-sided circuit boards in products. Multiple *cheap* processors where one "better" processor could suffice, etc. And, I'd wager a boat load of ASM where a HLL would be *so* much easier on those poor programmers... I've never met a manager who wouldn't try to figure out a way to cram some extra functionality into a product *or* trim a tiny bit of resource out of it -- when dealing with volume products. Your first offering may be "wasteful", but you quickly refine it to cut the waste out (get your foot in the door to get market share, then figure out how to boost profit and/or give yourself more margin to compete with other vendors on price) And, time spent *now* can be leveraged in future product designs. Save a penny now and you've also saved it tomorrow. > For a lot of applications, preposterously cheap horsepower has > outstripped our ability to use it all up. Failing to pay attention to > that fact is like pretending you can still only get a forward beta of > 50. Times change, parts improve, engineers still need sleep every now > and again. Why don't we see 32b processors in mice? Hell, think of how many cheaper programmers you can hire if you can code the application in Python and run it on a 100MHz CPU! Look at all the time those programmers can then spend sleeping! :> Why isn't ethernet connectivity *more* common? Heck, you've got all those resources just sitting there! Add a PHY and a connector (or, a radio, etc.) When you're buying them by the millions, everything is *free*! The next generation of parts can have the PHY and connector *on* the silicon! :-/
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-07-30 08:51 +0300 |
| Message-ID | <jjkev8tv9upuc651tqq3n12darp6k4u3d5@4ax.com> |
| In reply to | #213 |
On Mon, 29 Jul 2013 16:41:31 -0700, Don Y <this@isnotme.com> wrote: >Hi Rob, > >On 7/29/2013 3:42 PM, Rob Gaddi wrote: >> On Mon, 29 Jul 2013 15:20:45 -0700 >> Don Y <this@isnotme.com> wrote: >> >>> On 7/29/2013 3:11 PM, upsidedown@downunder.com wrote: >>> >>>> That is a pretty good figure, I would be quite happy with 50 % CPU >>>> utilization :-) >>> >>> But there are other scheduling algorithms that approach 100%! >>> If you are building something that you intend to sell, excess >>> capacity is wasted capacity is lost profit (or, increased price). >> >> Now THERE's a statement that's true when it's true and not when it's >> not. Let's say that for $0.25 a processor more I can shave two weeks of >> finagling with optimization. In a world with $1 Cortex M0 >> processors, that number is if anything high, it's probably closer to >> $0.10. >> >> Assume two weeks of my time plus two weeks earlier to market is worth >> $4K. I can sell 16,000 pieces before I make up that two week >> difference. > >You are thinking in small numbers! How many refrigerators do >you think *one* manufacturer sells IN A YEAR (forget about >next year)? How many irrigation controllers? Televisions? >Dishwashers? etc. > >I've worked in industries where the saying was "you're paying for >the plastic" (that the device is encapsulated in). There has been a long discussion about HRT vs SRT and suddenly there is a jump to cheap consumer products, which in general do not need any RT properties. If some time critical performance is needed in huge mass produced systems, these are usually implemented with ASICs.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-30 09:09 +0100 |
| Message-ID | <RwKJt.14224$oo1.7216@fx14.am4> |
| In reply to | #216 |
On 30/07/13 06:51, upsidedown@downunder.com wrote:
> If some time critical performance is needed in huge mass produced
> systems, these are usually implemented with ASICs.
The number of systems manufactured is irrelevant;
other aspects are more important, particularly
time-to-market and item cost.
You use hardware (e.g. ASICs) if:
- the latency between stimulus and response is
shorter than can be guaranteed with software
- the time interval within which a response is
required is shorter than can be guaranteed by
software
(where "guaranteed by software" includes all the
uncertainty introduced by hardware, e.g. cache
misses and, for more complex processors, TLB
misses.)
In most cases, typically the hardware is "armed"
by software to do something when a hardware event
occurs. The "arming" is still an HRT requirement,
but it can occur within a larger time window.
For example in a cellular base station controller
I implemented, frames had to be sent once every
4.518ms +- <1us at a bitrate of 271kb/s
- creating the frames' contents was HRT and
done by software filling a buffer
- transmitting the frame was done by hardware
shifting the data out of the buffer
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-30 01:30 -0700 |
| Message-ID | <kt7tjc$mie$1@speranza.aioe.org> |
| In reply to | #217 |
Hi Tom,
On 7/30/2013 1:09 AM, Tom Gardner wrote:
> On 30/07/13 06:51, upsidedown@downunder.com wrote:
>> If some time critical performance is needed in huge mass produced
>> systems, these are usually implemented with ASICs.
>
> The number of systems manufactured is irrelevant;
> other aspects are more important, particularly
> time-to-market and item cost.
>
> You use hardware (e.g. ASICs) if:
> - the latency between stimulus and response is
> shorter than can be guaranteed with software
> - the time interval within which a response is
> required is shorter than can be guaranteed by
> software
- when the functionality is well defined and
unlikely to require change (e.g., a dimmer
in an electronic light switch)
- the "processing" required exceeds the throughput
of an affordable processor (e.g., digitizing
raw video -- definitely HRT!)
> (where "guaranteed by software" includes all the
> uncertainty introduced by hardware, e.g. cache
> misses and, for more complex processors, TLB
> misses.)
Note that on "cheap consumer devices" (not my words)
you often don't have cache, MMU, etc. I.e., you can
actually "count cycles" (or have a development tool
do it for you) and get a deterministic value.
> In most cases, typically the hardware is "armed"
> by software to do something when a hardware event
> occurs. The "arming" is still an HRT requirement,
> but it can occur within a larger time window.
>
> For example in a cellular base station controller
> I implemented, frames had to be sent once every
> 4.518ms +- <1us at a bitrate of 271kb/s
> - creating the frames' contents was HRT and
> done by software filling a buffer
> - transmitting the frame was done by hardware
> shifting the data out of the buffer
On a cruder scale, a UART fills a similar role for
a similar reason (you wanna twiddle an I/O *pin*
to implement a 115Kbaud serial port? What about
a pokey 9600 baud??
To illustrate the pressure on hardware costs...
I had a manager once try to twist my arm to pare
down a group of 16b counters to *8* bit counters
to save $2 on a $300 (DM+DL) device. Even though
the processor would then spend 15% of real time
(no hyphen) doing:
save_state;
high_byte++;
restore_state;
Um, no.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-30 10:04 +0100 |
| Message-ID | <8kLJt.39350$3j2.25990@fx07.am4> |
| In reply to | #219 |
On 30/07/13 09:30, Don Y wrote: > Hi Tom, > > On 7/30/2013 1:09 AM, Tom Gardner wrote: >> On 30/07/13 06:51, upsidedown@downunder.com wrote: >>> If some time critical performance is needed in huge mass produced >>> systems, these are usually implemented with ASICs. >> >> The number of systems manufactured is irrelevant; >> other aspects are more important, particularly >> time-to-market and item cost. >> >> You use hardware (e.g. ASICs) if: >> - the latency between stimulus and response is >> shorter than can be guaranteed with software >> - the time interval within which a response is >> required is shorter than can be guaranteed by >> software > > - when the functionality is well defined and > unlikely to require change (e.g., a dimmer > in an electronic light switch) Yes, but I think that this comes under the "component/item cost" category, and is definitely outside the "time-to-market" category. > - the "processing" required exceeds the throughput > of an affordable processor (e.g., digitizing > raw video -- definitely HRT!) Yes, but I'll claim that is included in the time constraints! >> (where "guaranteed by software" includes all the >> uncertainty introduced by hardware, e.g. cache >> misses and, for more complex processors, TLB >> misses.) > > Note that on "cheap consumer devices" (not my words) > you often don't have cache, MMU, etc. I.e., you can > actually "count cycles" (or have a development tool > do it for you) and get a deterministic value. Yes indeed. But then I don't know how to do HRT on a system which has a cache.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-30 02:55 -0700 |
| Message-ID | <7x1u6gmkwv.fsf@ruckus.brouhaha.com> |
| In reply to | #220 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > But then I don't know how to do HRT on a system which has a cache. It looks to me like (some) HRT processors go even further and have no pipelines in addition to no caches, making timing of each instruction completely deterministic. I've fooled around with an HRT language (Atom) which has no "if" statement (something that selects between two blocks of code based on a condition, and executes just one of the blocks). It instead has a "mux" statement, which unconditionally executes both blocks, giving results r1 and r2. It then uses the condition to select one of the two results and discard the other. That way the statement takes the same amount of time regardless of the condition.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-30 07:12 -0700 |
| Message-ID | <kt8hkm$fni$1@speranza.aioe.org> |
| In reply to | #220 |
Hi Tom, On 7/30/2013 2:04 AM, Tom Gardner wrote: >>> You use hardware (e.g. ASICs) if: >>> - the latency between stimulus and response is >>> shorter than can be guaranteed with software >>> - the time interval within which a response is >>> required is shorter than can be guaranteed by >>> software >> >> - when the functionality is well defined and >> unlikely to require change (e.g., a dimmer >> in an electronic light switch) > > Yes, but I think that this comes under the > "component/item cost" category, and is definitely > outside the "time-to-market" category. I was trying to draw attention to the "unlikely to change" issue. I.e., even during development (as turning the crank on another iteration can be expensive -- in terms of dollars and calendar time). E.g., tens of kilobucks and a month or more. (not the sort of approach you want to take when the marketeering guys are likely to come in and say, "Why don't we make it *blink* as the intensity level is changing?" :> ) >> - the "processing" required exceeds the throughput >> of an affordable processor (e.g., digitizing >> raw video -- definitely HRT!) > > Yes, but I'll claim that is included in the time > constraints! Yeah, I guess so. I was specifically thinking of a configurable (dot clock, frame geometry) video digitizer I worked with that digitized video at dot clocks of up to 200MHz (back in the 90's... unlikely you're going to do that "in software" even if you had flash converters that fast! Assuming you *could* implement the sampling PLL with enough precision "in software" :> ) >>> (where "guaranteed by software" includes all the >>> uncertainty introduced by hardware, e.g. cache >>> misses and, for more complex processors, TLB >>> misses.) >> >> Note that on "cheap consumer devices" (not my words) >> you often don't have cache, MMU, etc. I.e., you can >> actually "count cycles" (or have a development tool >> do it for you) and get a deterministic value. > > Yes indeed. > > But then I don't know how to do HRT on a system > which has a cache. One approach would be to ignore the effect of the cache and assume all references were misses. I.e., if your scheduling, etc. assume worst case times for each I/D fetch/store AND GUARANTEE TIMELINESS, then if they happen to occur a bit quicker, on average, you err on the "early" side? Use any "gains" to increase the likelihood of SRT deadlines being met on time (vs tardy) or even "early". My day to scrounge around the discards. Always a tricky balance bringing home toys and risking the ire of SWMBO! Maybe I'll find an electric wheelchair that I can instrument! Wish me luck! <grin>
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-30 16:59 +0100 |
| Message-ID | <dpRJt.14581$%G1.8597@fx36.am4> |
| In reply to | #224 |
On 30/07/13 15:12, Don Y wrote:
> My day to scrounge around the discards. Always a tricky
> balance bringing home toys and risking the ire of SWMBO!
I have two solutions to that priblem:
- don't have a SWMBO (daughter doesn't count :)
- have a house that is *full*. Then you know if you
get anything new you have to achieve the
impossible: throw something else out. Great way
of saving money :)
> Maybe I'll find an electric wheelchair that I can instrument!
And then double the speed/power of the motors?
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-30 13:17 -0700 |
| Message-ID | <kt9704$dt7$1@speranza.aioe.org> |
| In reply to | #226 |
Hi Tom, On 7/30/2013 8:59 AM, Tom Gardner wrote: > On 30/07/13 15:12, Don Y wrote: >> My day to scrounge around the discards. Always a tricky >> balance bringing home toys and risking the ire of SWMBO! > > I have two solutions to that priblem: > - don't have a SWMBO (daughter doesn't count :) No daughter(s) -- that I *know* about! -- so that's not a problem (though I imagine they *could* be!) > - have a house that is *full*. Then you know if you > get anything new you have to achieve the > impossible: throw something else out. Great way > of saving money :) I've already been hard at work trying to "lighten the load". Too much stuff accumulated over the years and not enough time *left* to make use of it all! :> But, finding "good homes" for everything (instead of The Dump) means it's a fairly complex problem to shed weight! :< >> Maybe I'll find an electric wheelchair that I can instrument! > > And then double the speed/power of the motors? Ha! No. I'd like to be able to take advantage of the rest of the home automation/instrumentation to enhance "mobility" within the home/edifice. I.e., get the rider from point A to point B without requiring the rider to finely control the motion of the chair. A year ago, I was offered a nice, small chair. But, it was way too fast! 6 MPH! Put that in a home and you'd have to replace all the walls before you got the control algorithms anywhere near workable! :< (would have made a great little outdoor vehicle, though!) [Apparently, they have controllers in them that can be used to tweek the acceleration/velocity profile. But, I'm not sure how much actual control is possible. Perhaps just chopping the battery supplied to the motor and let the inductance of the windings shape the output? <shrug> ]
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.realtime
csiph-web