Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #12706 > 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 118 — 12 participants |
Back to article view | Back to comp.arch.embedded
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
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| 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 | #12847 |
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 | #12848 |
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 | #12848 |
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 | #12852 |
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 | #12854 |
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]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-30 10:12 -0700 |
| Message-ID | <7xfvuw7z0i.fsf@ruckus.brouhaha.com> |
| In reply to | #12852 |
Don Y <this@isnotme.com> writes: > 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, This could be a 1000 to 1 slowdown on a big x86, or maybe even more. Assume L1, L2, and L3 caches all miss on the different levels of page table pages as well as the address itself, plus the TLB misses.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-30 18:48 +0100 |
| Message-ID | <W%SJt.12384$z47.7332@fx35.am4> |
| In reply to | #12852 |
On 30/07/13 15:12, Don Y wrote: > On 7/30/2013 2:04 AM, Tom Gardner wrote: > >> 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. Ah, but how could you determine what degree of pessimism should you apply? IIRC the i960 allowed you to execute code then lock down its cache so that it wouldn't change and would therefore be repeatable. 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!
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-30 20:18 -0700 |
| Message-ID | <kt9vll$6v9$1@speranza.aioe.org> |
| In reply to | #12860 |
Hi Tom, On 7/30/2013 10:48 AM, Tom Gardner wrote: > On 30/07/13 15:12, Don Y wrote: >> On 7/30/2013 2:04 AM, Tom Gardner wrote: >> >>> 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. > > Ah, but how could you determine what degree > of pessimism should you apply? IIRC the i960 > allowed you to execute code then lock down its > cache so that it wouldn't change and would > therefore be repeatable. 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! 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. [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!)]
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-07-31 09:27 +0300 |
| Message-ID | <da8hv85sbrkc1n1svmqfgdd923v58dkjff@4ax.com> |
| In reply to | #12870 |
On Tue, 30 Jul 2013 20:18:12 -0700, Don Y <this@isnotme.com> wrote: >Hi Tom, > >On 7/30/2013 10:48 AM, Tom Gardner wrote: >> On 30/07/13 15:12, Don Y wrote: >>> On 7/30/2013 2:04 AM, Tom Gardner wrote: >>> >>>> 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. >> 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. >>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. >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. For instance when handling large number of serial lines (8-32 lines/PCI card), there is not much point trying to run this with character level interrupts on big x86 processors. In practice, all the cards are scanned for input and output data in every system clock interrupt, which might occur every 1 ms or every 10 ms. This is not so bad for full-duplex traffic, such as TCP/IP over PPP, however, but the throughput drops drastically with any half-duplex protocols are used, especially with 10 ms poll rate. IMO, trying to do low level time critical operations with a big general purpose processor is not very productive. >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. >[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 ! 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.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-31 00:47 -0700 |
| Subject | Re: Resource revocation [long] |
| Message-ID | <ktafdk$909$1@speranza.aioe.org> |
| In reply to | #12871 |
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!]
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-30 02:50 -0700 |
| Message-ID | <7x61vsml4v.fsf@ruckus.brouhaha.com> |
| In reply to | #12847 |
Don Y <this@isnotme.com> writes: > - the "processing" required exceeds the throughput > of an affordable processor (e.g., digitizing > raw video -- definitely HRT!) If buffering is allowed then as long as the throughput is higher than the frame rate, there's not a hard deadline for encoding a specific frame. Some frames or subframes can take longer than others. If some subframe is very complex and encoding takes too long and it can't be mitigated by buffering, the encoder fails and there is an artifact in the video. Cheap consumer video stuff has encoding artifacts all the time, though I don't know if this is the reason. From the observation that consumers don't complain too much about occasional artifacts though, it sounds like encoding is an SRT problem.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-07-30 13:22 +0300 |
| Message-ID | <a94fv8tqb5a5c4l3cri67e0absaim5vqu1@4ax.com> |
| In reply to | #12849 |
On Tue, 30 Jul 2013 02:50:56 -0700, Paul Rubin <no.email@nospam.invalid> wrote: >Don Y <this@isnotme.com> writes: >> - the "processing" required exceeds the throughput >> of an affordable processor (e.g., digitizing >> raw video -- definitely HRT!) > >If buffering is allowed then as long as the throughput is higher than >the frame rate, there's not a hard deadline for encoding a specific >frame. Some frames or subframes can take longer than others. > >If some subframe is very complex and encoding takes too long and it >can't be mitigated by buffering, the encoder fails and there is an >artifact in the video. Cheap consumer video stuff has encoding >artifacts all the time, though I don't know if this is the reason. From >the observation that consumers don't complain too much about occasional >artifacts though, it sounds like encoding is an SRT problem. Video processing is quite often a SRT issue. In the simplest case, a missed deadline can be handled by repeating the previous frame once and no one will notice. Only after consecutive loss of deadlines this will become evident (freezed frames). In MPEG, a missed (bidirectional) B-frame is no real issue. Missing I or P frames in decoding will cause artifacts during the GOP sequence (typically 0.5 s). On the encoding side, loosing a P-frame generation is no big deal, you can just accumulate the differences to the next P-frame (slightly more jerkiness). Failing to generate the I-frame will cause artifacts for the next GOP (less than 1 s).
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-30 07:24 -0700 |
| Message-ID | <kt8ibm$hqi$1@speranza.aioe.org> |
| In reply to | #12849 |
Hi Paul, On 7/30/2013 2:50 AM, Paul Rubin wrote: > Don Y <this@isnotme.com> writes: >> - the "processing" required exceeds the throughput >> of an affordable processor (e.g., digitizing >> raw video -- definitely HRT!) > > If buffering is allowed then as long as the throughput is higher than > the frame rate, there's not a hard deadline for encoding a specific > frame. Some frames or subframes can take longer than others. No, you still have a hard deadline. Just that you can release the task for the next frame, early. (and, "throughput" is "throughput" regardless of how it may be skewed in time -- if the processor can process X pels per second and the video stream has X+1, sooner or later the processor will drop a pel... fail to "see" it, entirely) (I wasn't talking about "encoding" video. Rather, *digitizing* it -- moving from the analog domain to the digital) > If some subframe is very complex and encoding takes too long and it > can't be mitigated by buffering, the encoder fails and there is an > artifact in the video. Cheap consumer video stuff has encoding > artifacts all the time, though I don't know if this is the reason. From > the observation that consumers don't complain too much about occasional > artifacts though, it sounds like encoding is an SRT problem.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-30 01:17 -0700 |
| Message-ID | <kt7sq6$kaq$1@speranza.aioe.org> |
| In reply to | #12844 |
On 7/29/2013 10:51 PM, upsidedown@downunder.com wrote: > 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. *Someone* <gasp!> claimed excess capacity was OK -- even desirable! I pointed out that it is not (we don't all design nuclear power plant controllers that number in the scores with 10 digit price tags over a 50 year timespan -- talk about "high volume"... NOT!). Does a PDA need RT capabilities? Can it just push a bit at a time out the Ir link to a printer to print a spreadsheet? No timing dependencies in those protocols? Does it have dedicated hardware that interfaces to the host PC via USB and just presents complete "file images" that it clocks into FLASH at its leisure? Does it scan the touchpad without regard for time and *hopefully* deduce that you drew a 5 and not an S? OK, well, maybe PDAs don't qualify as "cheap". I guess cheap cell phones might not, either! ? What about a UPS? Do you think it just switches to battery power whenever it gets around to it? And, detects loss of power by monitoring some DC voltage level on a pin (vs. watching zero crossings -- "Hmmm... I wonder when I should expect that next zero crossing to come along)? Do you think it generates a 32Hz waveform at some times and 79Hz at other times? Do you think it reports to the host (USB or serial) a bit at a time (and hopes the host can sort out what it intends, in the absence of signal timing)? What about a setback thermostat? Is the time that it displays something you *hope* is correct? "Yeah, I would like you to turn the temperature UP at 7AM so the house is warm when I climb out of bed. But, if you've missed a few deadlines and have, thus, lost time, then I guess 9AM would be OK, too!" What about a mouse? Do you think the quadrature detectors *hope* they see the right signals to determine the proper direction of motion? And, that the BT radio sorta-kinda decides when to hop to the next frequency whenever it feels like it? Or, the USB interface works whenever the mouse decides it wants to put stuff on the signal pair? [Note, we're now in the sub $30 retail market. I.e., DM+DL well below $10] What about an electronic *toaster*? Or, toaster oven? Or, a DVD *drive* (not a "player")? Hell, it's user interface is a light and a button! Of course, it's unlikely that they use "heady" techniques like RMA for scheduling. They probably treat everything as HRT and DON'T CARE if they *often* miss deadlines. But, that doesn't make them NON-RT designs! > If some time critical performance is needed in huge mass produced > systems, these are usually implemented with ASICs. If those ASICs are mask programmed MCU's, you're probably right! (kinda hard to imagine they would put an FPGA in a device like these -- since so many of them are end-user REPROGRAMMABLE -- and MCU's are *so* much cheaper and OTS!!) OTOH, if they are genuine ASICs, then that would be a validation of my claim that excess resources are shunned -- do you think they design ASICs with UNUSED counters, gates, pins drivers, etc.? "Hey, lets put some extra silicon in here so we can be glad we've got some to spare!" Of course, my opinion is a bit biased as I've taken apart lots of various types of devices -- just to see what's inside! :> Try it sometime! You;ll be amused at what you find (e.g., unencapsulated die, DIPs on single sided boards, trim pots (ick!) etc.) --don
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-29 19:28 -0700 |
| Message-ID | <7x4nbchjbs.fsf@ruckus.brouhaha.com> |
| In reply to | #12831 |
Don Y <this@isnotme.com> writes: > You might want to read his entire treatise,... > before dismissing his (well thought out) argument. I did look at it. That he's "arguing" something means by definition that his claims are not currently universally accepted. I'm not dismissing what he says, but just saying that he says one thing and other authors say things that are different, so there's a mix of valid viewpoints and I don't see a case for having one shut out the others. Any really precise formulation of a problem's requirements have to be part of the description of that specific problem. >> In an SRT ... you can estimate or measure the distribution of >> those timing variations... > You're leaving performance entirely to chance. Well yes, In some sense that's the idea of SRT, that performance is probabilistic and you're ok if you've got some (maybe informal) bounds on the probability distribution. > Making no attempt to maximize it! The idea is just to meet a specification. Are you confident (to whatever assurance level the product is designed to) that it's fast enough to meet the requirements? If yes, ship it. If not, go do some more work speeding it up, or upgrade the hardware, or whatever. >> HRT requires sharp bounds on every operation > Yeah, but the approach you described is exactly how you tackle HRT! > You figure out what its worst case performance characteristics are Figuring out the worst case is different than figuring out a probability distribution. Example: you have a 1024 byte (8192 bit) array, initialized to zero. You have a reliable hardware random number generator. You want to select exactly 1000 of the array's bits at random and set them to one, within a deadline. How would you do that in an SRT system? How would you do it in an HRT system?
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-07-29 11:40 +0300 |
| Message-ID | <tg9cv8hl9hs430kjvolf0smv4csit9epb8@4ax.com> |
| In reply to | #12821 |
On Mon, 29 Jul 2013 00:23:22 -0700, Don Y <this@isnotme.com> wrote: > >(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.) With a pre-emptive priority based system, in practice there can only be HRT operations in the highest priority level (known kernel latencies and the sum of the worst case subtasks execution times). Trying to calculate any hard deadlines on the lower priority levels would require first calculating the higher priority loading and then adding own workload . In a practical system, all HRT activities are executed at highest priority with well defined maximum execution times. The lower priority levels are then suitable for SRT and even lower for some bulk operations, assuming of course that the pre-emption latencies are low. When designing real time systems, I usually first look what operations can be moved to a _lower_ priority or even execute in the NULL task, then split high priority operations to short transactions, which are even shorter at higher priority levels. With such division of labour, the system usually run quite nicely as such and if HRT is needed, it is easy to just check that the tasks at highest priority meet the requirements.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-29 11:44 -0700 |
| Message-ID | <kt6d6o$u5h$1@speranza.aioe.org> |
| In reply to | #12824 |
Hi, On 7/29/2013 1:40 AM, upsidedown@downunder.com wrote: > On Mon, 29 Jul 2013 00:23:22 -0700, Don Y <this@isnotme.com> wrote: >> (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.) > > With a pre-emptive priority based system, in practice there can only > be HRT operations in the highest priority level (known kernel > latencies and the sum of the worst case subtasks execution times). Only the *topmost* priority can be regarded as having any "right" to use the processor. I.e., you have to determine that this task *won't* be using the processor before you can figure out what resources the NEXT highest priority task (or task set) will consume. And the next; and the next; etc. But the scheduling algorithm can be chosen to intelligently pick *which* tasks execute in order to maximize/guarantee they meet their deadlines. > Trying to calculate any hard deadlines on the lower priority levels > would require first calculating the higher priority loading and then > adding own workload . Exactly. (Simple) priority based schedulers only produce optimum (or even correct!) schedules if there are surplus resources. I.e., underutilized hardware. And, they lead to the "squeezed balloon" syndrome: something stops working (because it's priority isn't high enough given the current workload of higher priority tasks) so you goose its priority. Then, something ELSE stops working... Sort of like trimming the legs on a wobbly table: "oops! too short! Let me trim down the other legs to match... oops!..." With a science/math based approach to scheduling theory, you can actually figure out *if* a task set can be scheduled instead of running the app monte carlo style and watching for failures. > In a practical system, all HRT activities are executed at highest > priority with well defined maximum execution times. The lower priority > levels are then suitable for SRT and even lower for some bulk > operations, assuming of course that the pre-emption latencies are low. > > When designing real time systems, I usually first look what operations > can be moved to a _lower_ priority or even execute in the NULL task, > then split high priority operations to short transactions, which are > even shorter at higher priority levels. Yes. Much like shrinking atomic regions (*the* highest priority activity) to their smallest practical form. > With such division of labour, the system usually run quite nicely as > such and if HRT is needed, it is easy to just check that the tasks at > highest priority meet the requirements. If you provide the application with information about individual task deadlines, then the scheduler can evaluate these "live" (avoiding the phrase "in real time") to best decide which task to run -- without assigning arbitrary priorities (to tasks which often conceptually *share* a priority level OR which have been incorrectly assigned priorities based on some concept of "importantness") See, for example, rate monotonic and EDF scheduling algorithms (among others).
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-29 20:56 +0100 |
| Message-ID | <1OzJt.15365$Zi1.8525@fx15.am4> |
| In reply to | #12821 |
On 29/07/13 08:23, Don Y wrote: > 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)" Too simplistic. I once implemented a lung ventilator. If the airway pressure was too high and I missed a 50ms deadline for reducing it, does that mean the the system was brittle and over specified? (I accept that the human part of the system would have been brittle under those circumstances, but as I haven't seen a spec for a human I can't comment on whether humans are over-specified :) Ditto missing a deadline for having a breath! Of course, "deadline" is peculiarly apt terminology in these circumstances :)
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-29 13:16 -0700 |
| Message-ID | <kt6iih$ec8$1@speranza.aioe.org> |
| In reply to | #12832 |
Hi Tom,
On 7/29/2013 12:56 PM, Tom Gardner wrote:
> On 29/07/13 08:23, Don Y wrote:
>> 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)"
>
> Too simplistic.
>
> I once implemented a lung ventilator. If the airway pressure
> was too high and I missed a 50ms deadline for reducing it,
> does that mean the the system was brittle and over specified?
You've misread my comment. Since you MISSED that HARD deadline
(in a HARD *system*, not just a hard *task*), you obviously
didn't specify *enough* resources in your system design to
guarantee *meeting* the deadline. (even if those resources
would seldom have been needed/used)
[Alternatively, the system you have defined does not meet the
stated qualification of "HARD RT *system* -- it just happened to
be *a* RT system that had a hard deadline that it happened
to have missed. Presumably, the system specification gave
you some leeway in how many of these deadlines you *could*
miss and still be considered "functional". Perhaps "miss no
more than one out of every ten and never two consecutively".
Such a specification would be an acknowledgement that trying
to meet every such deadline would be too costly to implement;
i.e., contain far more resources than necessary probabilistically]
Cf:
"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"
and:
"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."
I.e., if your system specification ALLOWED you to miss that one
deadline, then it wasn't a hard real-time system!
That's why it's important to have a taxonomy and well-defined
means of categorizing problems and implementations. So its
more than just :this *seems* like it is more important than
that" (OK, then that should be reflected by the system
design and metrics that let others come to that same conclusion.)
Instead, we get folks conflating speed/frequency, safety, damage,
monetary cost, etc. -- all things that have emotional appeal
but no real scientific/mathematical basis (that could be fed into
a scheduling algorithm, etc.)
> (I accept that the human part of the system would have been
> brittle under those circumstances, but as I haven't seen a
> spec for a human I can't comment on whether humans are
> over-specified :)
>
> Ditto missing a deadline for having a breath!
>
> Of course, "deadline" is peculiarly apt terminology in these
> circumstances :)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2013-07-30 00:08 -0400 |
| Message-ID | <T_GJt.806$0q1.763@en-nntp-06.dc1.easynews.com> |
| In reply to | #12821 |
On 7/29/13 3:23 AM, Don Y wrote: > Hi Richard, > > On 7/28/2013 9:10 PM, Richard Damon wrote: >> 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. > Only by this authors crazy, self defined definitions. From what I read of his work, he is an academic, and make the mistake of using the wrong tools for the job. His quote that "Hard Real Time is hard, Soft Real Time is harder", shows that he does NOT understand how to do it in real life. You can get this result if you try to prove the validity of a Soft Real Time operation to the level needed for a robust Hard Real Time operation. He also doesn't seem to understand the concept of real requirements (since he tolerates allowing a hard real time operation to fail, and talks about rescheduling thing when this happens). Hard requirements are HARD, they are MUST DOs, failure is NOT an option. Occasionally you are given a small allowance for failure to handle situations beyond the systems control. You likely have code for cases where the failure occurs, as a form of damage control, but if this executes (except for violation of the contract with that system, or conditions beyond it control) then the customer can rightfully say the system has failed it function and is defective. Hard Real Time design requires an exhaustive worst case analysis. This is a lot of work, and requires a lot of testing to make a good attempt at forcing the worse case situations, and to make sure all cases have been analyzed and checked. Soft Real Time requirements, on the other hand, don't require looking at "worse case" cases, but typically operating at some minimum level of average performance. We don't need to find the absolute worse case paths, but just the "slightly unlucky cases". Because they are based on averages, we can normally use the law of large numbers to analyze things. This allows us to simplify the analysis. A system with Hard Real Time requirements needs to have a Hard Real Time analysis performed on it, which normally requires that the system was designed with Hard Real Time in mind, and thus is a Hard Real Time system. If you system has only been analyzed to the Soft Real Time level, then it is extremely hard, if not impossible, to do the analysis needed for a Hard Real Time operation within it. You basically can't make a guarantee that a non-trivial Real Time operation will met a non-trivial Hard deadline without a system design based on being able to make Hard Real Time guarantees. >> 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.) > I agree, that many things called hard real time are not, things that are not needed to meet critical objectives, things that we just like having happening real fast, things that if we don't get them done by the deadline made us waste the resources we put into it because it no longer has value. A Hard requirement is one essential to meeting the critical performance requirements of the system. A Hard Deadline is a deadline that the design says must be met to meet these requirements. This doesn't mean that Hard Requirements don't exist. I will admit that some "Hard" Requirements are defined as Hard, not because they really need to be, but because it makes the analysis of the system above you easier, but unless you have real input into that system, you need to live with the requirements flowed down to you and specified in your contract. (Sometimes if you find something really impossible to met, you can renegotiate the requirements, but that is well beyond this discussion). Similarly, often you will take your Hard requirements and to implement it, assign Hard deadlines to sub tasks, so that the system is analyzable, as it is difficult to give them "Soft" deadlines and combine them to a Hard result. >> (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! > I find individual deadlines rarely have individual value. If the deadline has been assigned as "Hard", then its failure has invalidated my design requirements to met by critical requirements, so the only important values are 1 and 0, and I better not hit any 0s. I never seem to have the option of doing one thing twice instead of two different things, as rarely are operations fungible as would be implied by a value function. Perhaps once you have met the "Hard", you can find some measures of value for how well you are doing above the critical requirements to meeting the optional and desired goals. I have never found trying to put "value" functions on operations to impact a scheduler making sense. You invariably spend more effort creating these functions (since there rarely is a natural value function), and too many resources evaluating it for the scheduler. Priorities tend to lend themselves to simple schedulers (so less overhead, and simpler analysis), and normally tend to fall out of a requirement analysis. Sometimes the priority order will come out of the requirements. Other times the requirements don't directly force the order of priority, but some orders are easier to analyze (you like high priority operations to be predictable in system load, and generally quicker). >>>> 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". As I said, "value" is normally not an applicable property for a hard reuirement. And there can be NOTHING more "valuable" than a Hard deadline, as deadlines being Hard means it is requirement for a critical requirement, and I never plan to "stop" on a Hard operation unless I need to concede that I have failed and am switching to damage control, and I need to be able to prove that this shouldn't happen under the defined operating conditions. > >>>> 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"?) You have OBVIOUSLY never worked on a system with TRUE Hard Requirements, or customers expecting that you deliver what you have promised. My customers tend to expect that I will met the critical performance requirements, often with penalties for not meeting them (not infrequently that we don't get paid anything for the work). Sometimes we do have an option to re-negotiate or get an exception for a MINOR miss in specification, but we still need to be able to make promises on worse case performance. Note that you seem to want to call a lot of things as having Hard Deadline that aren't, because you are using the wrong definition. I suppose that maybe the problem is that the site is talking about "computing systems", and not using "computing system" as part of a system doing something important (where failure means more than a bottle on the floor). > > "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 > Sounds very much like: "When I use a word," Humpty Dumpty said in rather a scornful tone, "it means just what I choose it to mean -- neither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." Claiming that a word means something different than it common usage is normally a sign that someone isn't really concerned with communicating.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web