Resource revocation - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Resource revocation
On 27/07/13 23:21, Paul Rubin wrote:
Quoted text here. Click to load it

That sort of thing.

Quoted text here. Click to load it

Agreed, unfortunately.

I was deliberately avoiding defining what
I meant by "proof" :)

Re: Resource revocation
Hi Hans-Bernhard,

On 7/26/2013 10:25 AM, Hans-Bernhard Bröker wrote:
Quoted text here. Click to load it

I think "gravity" suggests "safety critical", "life support", etc.
Rather, I view it as the *value* of a timely result.  I.e. if
your product picks bottles off a conveyor belt, then missing a
deadline means a bottle crashes onto the floor.  This might
be relatively insignificant in terms of its financial value, etc.

But, the effort expended trying to *get* the bottle before it
crashed to the floor has been wasted.  *And*, no further effort
will change the outcome!  (i.e., *drop* that task from your

Quoted text here. Click to load it

This is an excellent way of putting it!


Re: Resource revocation
On Fri, 26 Jul 2013 19:25:59 +0200,

Quoted text here. Click to load it

Although the usual easy definition of hard real-time is:
  "Late answers are wrong answers"
there are a few occasions when doing something too early is also
wrong. Hard real-time is really about doing things at the right  


Stephen Pelc,
MicroProcessor Engineering Ltd - More Real, Less Time
We've slightly trimmed the long signature. Click to see the full one.
Re: Resource revocation
On 7/26/13 1:25 PM, Hans-Bernhard Bröker wrote:
Quoted text here. Click to load it

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

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.

Re: Resource revocation
Hi Richard,

On 7/28/2013 3:31 PM, Richard Damon wrote:

[attributions elided]

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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")

Quoted text here. Click to load it

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!

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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

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.

Re: Resource revocation
On 7/28/13 6:51 PM, Don Y wrote:
Quoted text here. Click to load 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.

Quoted text here. Click to load it
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".

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: Resource revocation
Hi Richard,

On 7/28/2013 5:12 PM, Richard Damon wrote:
Quoted text here. Click to load it

No.  You deal with the events as events.  How you decide if the
*system* has failed is subject to other criteria -- unrelated to

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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)

Quoted text here. Click to load it

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!)

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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 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!

Quoted text here. Click to load it

Re: Resource revocation
On 7/28/13 9:35 PM, Don Y wrote:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it
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).

Re: Resource revocation
Hi Richard,

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

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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!

Quoted text here. Click to load it

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

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".

Quoted text here. Click to load it

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

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)

Quoted text here. Click to load it

      "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."


      "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

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


      "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


Re: Resource revocation
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: Resource revocation
Hi Paul,

On 7/29/2013 1:05 AM, Paul Rubin wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Sure!  But many of these the RT developer implements deterministically
instead of relying on some generic implementation NOT suited to RT.

Quoted text here. Click to load it

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>"

Quoted text here. Click to load it

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!

Re: Resource revocation

Quoted text here. Click to load it

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.

Re: Resource revocation
On 7/29/2013 3:11 PM, wrote:
Quoted text here. Click to load it

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!)

Quoted text here. Click to load it

Re: Resource revocation
On Mon, 29 Jul 2013 15:20:45 -0700

Quoted text here. Click to load it

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

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

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 --
Email address domain is currently out of order.  See above to fix.

Re: Resource revocation
Hi Rob,

On 7/29/2013 3:42 PM, Rob Gaddi wrote:
Quoted text here. Click to load it

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

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.

Quoted text here. Click to load it

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!  :-/

Re: Resource revocation

Quoted text here. Click to load it

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.

Re: Resource revocation
On 30/07/13 06:51, wrote:
Quoted text here. Click to load it

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
(where "guaranteed by software" includes all the
uncertainty introduced by hardware, e.g. cache
misses and, for more complex processors, TLB

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

Re: Resource revocation
Hi Tom,

On 7/30/2013 1:09 AM, Tom Gardner wrote:
Quoted text here. Click to load it

      - 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!)

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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:


Um, no.

Re: Resource revocation
On 30/07/13 09:30, Don Y wrote:
Quoted text here. Click to load it

Yes, but I think that this comes under the
"component/item cost" category, and is definitely
outside the "time-to-market" category.

Quoted text here. Click to load it

Yes, but I'll claim that is included in the time

Quoted text here. Click to load it

Yes indeed.

But then I don't know how to do HRT on a system
which has a cache.

Re: Resource revocation
Quoted text here. Click to load it

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.

Site Timeline