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

Groups > comp.arch.embedded > #12874

Re: Resource revocation [long]

Cross-posted to 2 groups.

Show all headers | View raw

Hi,

On 7/30/2013 11:27 PM, upsidedown@downunder.com wrote:

[Attributions elided]

>>>>> 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.
>
> Disable cache and verify that the HRT requirements are met.

Exactly.  "Things can only get *better*"  (this is actually
a little lie -- but, can almost always be ignored, in practice.)

>>> Ah, but how could you determine what degree
>>> of pessimism should you apply?
>
> 100 % for HRT. If there are some unused capacity in this case, then
> you can safely assume that some other non-RT or SRT tasks could be
> executed at "spare" time. This also gives a pessimistic guess, how
> much capacity is available. With cache enabled, this will decrease the
> HRT loading, leaving more time to non-RT and SRT processing.

Or, treat the cache as a resource that you can deploy selectively
to improve particular aspects of your implementation.  This is
akin to NOT using floating point in certain tasks to eliminate
the (often asynchronously implemented) overhead of the added
(possibly defered) extra context that needs to be saved/restored.

Or, *only* allowing floating point resources to be used in certain
tasks so the FP context need *not* be saved/restored to allow
that resource to be used in other tasks.

[Repeat for any other "expensive" resource access to which could
significantly change the performance of the system -- easy to
test/verify, etc.]

E.g., I am trying to develop a common hardware/software platform that
I can apply to 21 (?) different "designs/products" (because I don't
have the time or resources to develop 21 completely *different*
designs/products!).  Do I optimize each final design to make best
use of the resources (time/space/etc.)?  Or, do I optimize the
*core* portion of the design (RTOS, network stack, VM, VMM, etc.)
so the optimization applies across "products" -- even if this
means some product might be sub-optimal?  (what happens when a
different app is loaded on that product?  do I then re-optimize??)

I'm greedy in how aggressively I "fit" a design to its hardware
platform.  But, I'm not obsessive -- take the big wins and don't
sweat the little details.

Bringing it back to this issue, if hardwiring the cache lines
to ISR's gives you some measurable increase in PREDICTABLE
performance, it might not be the best you could achieve (given
infinite time to tune) but at least it's *an* improvement and
you can conceptually evaluate how further changes to the system
(ISRs and else) are likely to be "received" -- without undertaking
that "infinite tuning" again.

>>> IIRC the i960
>>> allowed you to execute code then lock down its
>>> cache so that it wouldn't change and would
>>> therefore be repeatable.
>
> Locking down areas in cache or virtual memory can easily have adverse
> effects, especially at low level caches, where fully associative
> mapping is not available. A locked line might be an alias with a
> frequently used application cache line, causing cache misses for any
> memory references to that area.

It can also change the order that tasks get scheduled (because the
completion times of some tasks are altered more than others).  Or,
interact with other resources in non-obvious ways.

>> If you can do this, then put key ISR's or oft-used
>> parts of the RTOS in those cache-lines,
>>
>>> Even on an i486 with its minimal cache you
>>> could see 10:1 variations.
>>>
>>> And if you have to be that pessimistic, why pay
>>> for all that extra power and cost for the cache
>>> and OOO hardware - which is, by definition,
>>> unnecessary!
>
> Frequent interrupts, OOO, long pipelines and huge cache hierarchy do
> not match very well. The interrupt causes some kind of (mini)context
> switch, requiring some of the processor state to be saved. In addition
> to flushing OOO and FIFOs, at least some registers need to be saved or
> at least an other register set must be activated. After exiting the
> ISR, the pipelines must be reloaded, possibly with additional cache
> misses.

Some processors have IRQs designed for "streamlined" ISRs.
E.g., the SA's FIRQ has an incredibly low overhead (but also
means you can't do quite as much without ADDING overhead)

Older processors tended to make the user more aware of the
cost of the context switch and offer hacks to allow more
easy exploitation (e.g., the Zx80's EXX and EX AF; PUL/PSH
on the 6809, etc.).  But, then again, they only risked the
cost of a short pipeline and the portion of the state
preserved.

> IMO, trying to do low level time critical operations with a big
> general purpose processor is not very productive.

---^^^^^^^^^^^^^ agreed.  Don't treat it as HRT since it almost
always *isn't* (folks just want to treat it that way because
it makes it easier to think about the consequences!  :> )

>> I design with very few HRT tasks -- and even fewer
>> whose deadlines absolutely *can't* be missed.  So,
>> this gives you assurance that the HRT works (always)
>> and all the acceleration brings the SRT load along
>> for free/cheap.
>
> Any time when the there is some unused time after the HRT tasks have
> been handled, is a bonus for SRT.

And, if your goal (i.e., mine) is to map damn near everything into
the SRT domain, then you have much more flexibility in how you
"solve" the problem (application).  There's almost always some
way to handle a missed deadline -- it just usually takes more
*thinking* about the solution!

E.g., my "network speakers" are largely HRT.  If the next audio
packet isn't here before I need it, there will be an audible
artifact (dropout, click, etc.).  I can't force the server to
give it to me when I need it (though it has been designed
with that explicit goal in mind!).  Nor can I prevent "something"
from interfering with the network transmission (noise from a
nearby flourescent light's starter coupling to the network cable
and corrupting a packet on its way to *this* device -- though
possibly not others!).

So, to say the system is broke because it misses a hard deadline
(hard: not worth pursuing once it has past) is silly.  Chances are
it will ALWAYS be broke (because you can't control the entire
environment!).

A naive implementation would deal with this by putting a large
buffer on the device so there was a longer time interval in which
a packet could be "retried", etc.  (bigger buffer == bigger cost)
Ah, but now the server has to be "ahead" of the speaker (client)
in terms of "REAL (chronological) time".  It has to deliver
audio packets long before the speaker needs to reproduce them!
I.e., greatly increased latency (imagine speaker is reproducing
audio that accompanies a video presentation -- now we have to
artificially delay the video to ensure the audio will be in sync
with it!).  (i.e., MORE cost -- but, at least it's not in the
"network speaker", eh?  :> )

And, you're *still* at the mercy of the proverbial shit hitting
the fan:  your overly large buffer not being enough to overcome
a prolonged anomaly in the system!  (what happens if the server
is momentarily overloaded?  Or, do you over-specify the server's
hardware so this "can't happen"??  See where this ends up going?)
I.e., for all that extra cost, you're still BRITTLE!

My initial implementation had the client request a packet that
didn't appear in a timely fashion (the server just pushes packets
to clients for each "subscription", normally; a client needn't
sit there constantly requesting packets -- wasted bandwidth and
processing in the clients AND the server!).

But, that meant I had to move up the "rerequest" deadline so
there would be enough time to get the reply to this rerequest
before it was actually needed.  And, meant the server had
to deal with all this extra *incoming* traffic -- which would
further hinder its ability to handle its primary *outgoing*
role!  (imagine a dozen clients all clamoring for dropped
packets... and, that effort causing other packets to miss
their *local* deadlines, etc.)

Second iteration the server designated a "backup" client for
each client.  I.e., some other client that was getting the same
feed (or, that it could command to accept the feed).  If a
client failed to receive a packet, it would contact it's
backup (buddy) -- in the hope that the backup client had the
packet.  This kept those requests from flooding the *one*
server that was trying to deal with all these clients.

[I've since fine-tuned this protocol so there is even less
overhead -- since overhead effectively moves a deadline closer
(or entices you to increase a buffer's depth)]

Point of (long) example is you think of ways to react to
your *expectation* that some deadlines will be missed.

[There is also deterministic handling of the case where
"too many" deadlines are missed:  you don't want to shut
off the speaker because it missed *a* deadline (brittle).
Nor do you want it "stuttering" as it meets some, then
misses some, then meets some, then...]

When the world is SRT, you afford yourself these extra
possibilities to improve performance WITHOUT adding
resources (buffer memory, latency, etc.).  *But*, you
then have to assume the responsibility for dealing with
these situations -- instead of just saying "system is
broken".

>> [The key is avoiding HRT as much as possible and learning
>> to optimize the performance of the SRT tasks -- so that
>> they are always "as good as possible".  In that case, you
>> can put a "dial" on the system oscillator and dial the
>> level of performance that you are willing to pay for
>> (since the SRT tasks are those that have variable worth!)]
>
> One should remember that in most RT systems, there is well specified
> _constant_ amount of work to be done every second. If the system is
> "overspecified" so that the CPU duty cycle of only 50 %, if you then
> drop the CPU clock frequency to one half, the duty cycle is going to
> increase to 100 %, the energy consumption will remain the same as will
> the heat generated !

Note that with SRT designs, you implicitly acknowledge performance
can *vary*.  I.e., a system can become more heavily utilitized in
the short term and shed some capability, accuracy, etc. -- yet
regain it "later" when the cause for the "heavier load" has disappeared.
Because you can reevaluate your ability to meet a missed deadline
instead of UNCONDITIONALLY dismissing or enforcing it!

E.g., I've designed systems that could be pushed beyond 100%
utilization, inherently shed responsibilities that they
*couldn't* meet (this isn't as important as that), then resumed
them once the short term load returned to normal.  All the while,
continuing to meet their stated design requirements (even as
performance appeared to suffer in the short term).

For example, you'd much prefer your ABS brakes to work (HRT)
than your ingition firing (also HRT) to continue "optimally"!
Yet, once you pulled out of the skid, you'd like to regain
the same fuel economy that you had prior to entering it!
(and, do so without having to add excess capacity for these
infrequent sorts of events)

[You want to BEND instead of BREAK -- flexible, not brittle]

> The only way you are going to save energy consumption and heat
> generation, is that it may be possible to reduce the operating voltage
> with a lower clock frequency. This can be quite significant, since the
> active state power consumption is proportional to the square of the
> operating voltage.
>
> But without lowering the operating voltage simultaneously, just
> dropping the clock speed does not  help much in a typical situation.

Sorry, I wasn't meaning that you did this, in fact.  (Though you
can also idle a processor that isn't needed for anything "now")

Rather, I was illustrating that performance now becomes something
you can tweek to fit your resources.  E.g., instead of an X MHz
processor that costs $Y, you can spec one that is only capable
of operating at Z MHz for a cost of $W.

E.g., in my immediate case, I have several different "products/designs"
that I would REALLY like to share a common hardware and software base.
There is *big* value in this!  At the same time, I don't want the
needs of the "most demanding" device to determine the *cost* of the
LEAST demanding!

So, I'd like to be able to spec different grade parts (same family
or base part number) for the "same" (hardware) design as befitting
the needs of the device that will actually "infect" that board.
Having to make provisions for external memory, for example, means
the core design has to be compromised to allow for that extra
real estate, power consumption, pin utilization, etc.

[If I was a *business* approaching this, I would care much less
about these issues.  But, if I want others to be able to
reproduce my efforts *economically*, the more I can do to
make things "the same", the better the result for them!]

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

Thread

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

csiph-web