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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-27 08:56 -0700 |
| Message-ID | <kt0qjl$m70$1@speranza.aioe.org> |
| In reply to | #12737 |
Hi Paul, On 7/26/2013 12:31 PM, Paul Rubin wrote: > Don Y <this@isnotme.com> writes: >> Certain services are considered "essential". ... these services >> could be replicated for higher availability >> E.g., the database service is heavily relied upon by all clients > > This really sounds more and more like you're reinventing Erlang. > That's ok, it happens all the time. You might benefit from: > > http://learnyousomeerlang.com/content When I set out, I looked for a mainstream language that was reasonably safe and efficient that would act more like a "scripting" language. I.e., most of the heavy lifting that an application would need would be available *to* the application as system services. The application would "simply" (ha!) tie those services together in a meaningful way. I settled on Limbo as it is sort of a "safer C" -- easy enough for folks conversant in C to pick up quickly. But, also including inherent support for IPC, strong type-checking, support for concurrency, etc. And, under Inferno, provides a VM platform that makes things like pushing a process to another processor relatively painless. As well as affording some protection mechanisms for collocated tasks (and their remote communications!) There are a few things about the language and environment that I'm not thrilled with, but, so far, it seems to have been a good choice. > FWIW, Erlang has a replicated, distributed database (non-relational, > more like an object db) built into its runtime. I opted for a full-fledged RDBMS (currently, PostgreSQL) as it lets tasks push a great deal of work back into the server. E.g., let the server implement the joins, triggers, checks, etc. instead of requiring the client/app to do all that detail. (remember, clients are reasonably strapped for resources!) It also helps ensure *all* clients of a particular DB follow the same constraints applied to the data *in* each table. So, some client doesn't add an entry that is incorrect and screw up some *other* client who expects, e.g., "person.age > 0" to have been enforced *in* the data! Otherwise, each client would have to implement more comprehensive checking on the data -- and, be capable and consistent in reporting any problems it encounters *to* the user! (i.e., "Age must be greater than zero" reported by one client's tests while another client opts to say "Not old enough", etc.) (It also lets me avail myself of advances in the development of the RDBMS just by "upgrading" my implementation to "-CURRENT" as appropriate) I'm happy with the software environment. But, having more problems than I anticipated with the instrumentation! :< --don
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2013-07-26 19:25 +0200 |
| Message-ID | <b5fpouFs6qcU1@mid.dfncis.de> |
| In reply to | #12719 |
On 26.07.2013 11:48, Paul Rubin wrote: > Don Y <this@isnotme.com> writes: > Hard deadlines in realtime programming usually mean microseconds or so. > This plant watering stuff isn't even soft realtime (where you generally > want responses within milliseconds but are allowed to miss > occasionally). This is a very common misconception, but still just as wrong. Realtime has nothing to do whatsoever with the length of any particular interval of time. It doesn't matter if your deadline is coming every 50 nanoseconds or once a year. If there's a deadline, and it's defined as a point fixed in time, then you're doing realtime processing. Nor is the distinction between soft and hard realtime to be found in the timescales involved, but in the gravity of consequences if you miss a deadline. In other words, realtime is about whether there _is_ a "too late", not _when_ that might be.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-26 10:51 -0700 |
| Message-ID | <7xd2q5b46d.fsf@ruckus.brouhaha.com> |
| In reply to | #12726 |
Hans-Bernhard Bröker <HBBroeker@t-online.de> writes: > Realtime has nothing to do whatsoever with the length of any > particular interval of time. It doesn't matter if your deadline is > coming every 50 nanoseconds or once a year. Pedantically you and Don are correct. In practice in terms of software technique, the interval lengths actually matter.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-26 19:21 +0100 |
| Message-ID | <I6zIt.18999$zk4.17046@fx18.am4> |
| In reply to | #12727 |
On 26/07/13 18:51, Paul Rubin wrote: > Hans-Bernhard Bröker <HBBroeker@t-online.de> writes: >> Realtime has nothing to do whatsoever with the length of any >> particular interval of time. It doesn't matter if your deadline is >> coming every 50 nanoseconds or once a year. > > Pedantically you and Don are correct. It isn't pedantic, since that is the only difference between hard and soft realtime. > In practice in terms of software > technique, the interval lengths actually matter. True, to a large extent. But not if, for example, the processor entered a sleep mode for 364.999 days, woke up and missed the deadline. Engineers are paid to be pessimists; if you don't want that characteristic, hire a marketeer :)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-26 11:50 -0700 |
| Message-ID | <7xbo5pp343.fsf@ruckus.brouhaha.com> |
| In reply to | #12728 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> It doesn't matter if your deadline is coming every 50 nanoseconds or >>> once a year. >> Pedantically you and Don are correct. > It isn't pedantic, since that is the only difference > between hard and soft realtime. Yes really. If I'm working on desktop tax preparation software, the software is useless if it can't figure out my taxes by April 15th. But to describe that as "hard realtime software" to a newsgroup of embedded developers who actually work on things like motion control is pedantic, ridiculous, or both ;-).
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-26 19:42 +0100 |
| Message-ID | <bqzIt.4519$bE7.887@fx33.am4> |
| In reply to | #12730 |
On 26/07/13 19:50, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>> It doesn't matter if your deadline is coming every 50 nanoseconds or >>>> once a year. >>> Pedantically you and Don are correct. >> It isn't pedantic, since that is the only difference >> between hard and soft realtime. > > Yes really. If I'm working on desktop tax preparation software, the > software is useless if it can't figure out my taxes by April 15th. I suspect the IRS imposes just as hard a deadline as the IR does here :) > But > to describe that as "hard realtime software" to a newsgroup of embedded > developers who actually work on things like motion control is pedantic, > ridiculous, or both ;-). To quote one of the many variants of the joke... GROUCHO MARX (to woman seated next to him at an elegant dinner party): Would you sleep with me for ten million dollars? WOMAN (giggles and responds): Oh, Groucho, of course I would. GROUCHO; How about doing it for fifteen dollars? WOMAN (indignant): Why, what do you think I am? GROUCHO: That’s already been established. Now we’re just haggling about the price.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-26 12:43 -0700 |
| Message-ID | <ksujgq$f8c$2@speranza.aioe.org> |
| In reply to | #12730 |
Hi Paul, On 7/26/2013 11:50 AM, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>> It doesn't matter if your deadline is coming every 50 nanoseconds or >>>> once a year. >>> Pedantically you and Don are correct. >> It isn't pedantic, since that is the only difference >> between hard and soft realtime. > > Yes really. If I'm working on desktop tax preparation software, the > software is useless if it can't figure out my taxes by April 15th. But > to describe that as "hard realtime software" to a newsgroup of embedded > developers who actually work on things like motion control is pedantic, > ridiculous, or both ;-). Actually, that's more of a "soft" RT problem. There is still value to filing your tax return after the 15th! It's just that the value *diminishes* (i.e., becomes a COST) after that date. I've known folks to file YEARS after the due date (incurring penalties in the meantime) Just because folks are controlling motors doesn;t mean they have a monopoly on RT. Nor do folks in safety critical application domains! Real-time == deadline. Period. --don
[toc] | [prev] | [next] | [standalone]
| From | Roberto Waltman <usenet@rwaltman.com> |
|---|---|
| Date | 2013-07-26 17:06 -0400 |
| Subject | Does the Buddha have a real time nature? ;) (was Resource revocation) |
| Message-ID | <b8o5v85soicm3i7fd52ktuq014lgqcmuja@4ax.com> |
| In reply to | #12739 |
Hans-Bernhard Bröker wrote: >... >In other words, realtime is about whether there _is_ a "too late", not >_when_ that might be. Don Y wrote: >... >Real-time == deadline. Period. I am always puzzled by those "definitions" (for lack of a better term) that seem to ignore the obvious: Real time is about windows/time slots in which an action is effective. i.e., too early is as bad as too late. For a few trivial examples: In a package sorting installation, the diverter that pushes out a box from a conveyor belt must operate when the box is in front of it, not after, not before. Firing a rocket to slow down a space craft for reentry must happen at the proper time, not "before" a certain time. Pushing down the cork in an automated bottling facility works best when the bottle is below it. And so on... -- Roberto Waltman [ Please reply to the group, return address is invalid ]
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-26 17:12 -0700 |
| Subject | Re: Does the Buddha have a real time nature? ;) (was Resource revocation) |
| Message-ID | <ksv399$m2k$1@speranza.aioe.org> |
| In reply to | #12745 |
Hi Roberto, On 7/26/2013 2:06 PM, Roberto Waltman wrote: > Hans-Bernhard Bröker wrote: >> ... >> In other words, realtime is about whether there _is_ a "too late", not >> _when_ that might be. > > Don Y wrote: >> ... >> Real-time == deadline. Period. > > I am always puzzled by those "definitions" (for lack of a better term) > that seem to ignore the obvious: Real time is about windows/time slots > in which an action is effective. i.e., too early is as bad as too > late. There is a bit of slight of hand, here. A task can not complete before it has begun (<grin>). So, if you alter the release time of the task (the time at which it becomes *available* to execute), you can shift the earliest completion point for the task. I.e., the start of your "window". Then, the deadline becomes the *end* of the window. Typically, when you are encountering these sorts of applications, you design so that you have the "answer", reliably, some time "around" the start of the window and then defer its effectivity until after the formal start of the window. The delaying action ensures the result is never *applied* before the window start while the deadline delimits the definition of "too late". We do this in hardware designs, too. Set-up signals and propagate them into their intended circuits "at the next clock edge", etc. > For a few trivial examples: > > In a package sorting installation, the diverter that pushes out a box > from a conveyor belt must operate when the box is in front of it, not > after, not before. > > Firing a rocket to slow down a space craft for reentry must happen at > the proper time, not "before" a certain time. > > Pushing down the cork in an automated bottling facility works best > when the bottle is below it. > > And so on...
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-27 09:44 +0100 |
| Subject | Re: Does the Buddha have a real time nature? ;) (was Resource revocation) |
| Message-ID | <sLLIt.29751$i03.21108@fx03.am4> |
| In reply to | #12747 |
On 27/07/13 01:12, Don Y wrote: > There is a bit of slight of hand, here. A task can not complete > before it has begun (<grin>). That isn't necessarily as clear as you might believe. If you check an English/Hindi dictionary you will find that the word for "yesterday" is the same as the word for "tomorrow" (कल pronounced "kal"). This is also deeply embedded (ho ho) in their culture, which doesn't have an "arrow of time" but does have a "wheel of time".
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-27 09:45 +0100 |
| Subject | Re: Does the Buddha have a real time nature? ;) (was Resource revocation) |
| Message-ID | <VMLIt.29752$i03.914@fx03.am4> |
| In reply to | #12747 |
On 27/07/13 01:12, Don Y wrote:> There is a bit of slight of hand, here. A task can not complete > before it has begun (<grin>). That isn't necessarily as clear as you might believe. If you check an English/Hindi dictionary you will find that the word for "yesterday" is the same as the word for "tomorrow" (कल pronounced "kal"). This is also deeply embedded (ho ho) in their culture, which doesn't have an "arrow of time" but does have a "wheel of time".
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-27 12:28 -0700 |
| Subject | Re: Does the Buddha have a real time nature? ;) (was Resource revocation) |
| Message-ID | <kt1702$neu$1@speranza.aioe.org> |
| In reply to | #12766 |
Hi Tom, On 7/27/2013 1:45 AM, Tom Gardner wrote: > On 27/07/13 01:12, Don Y wrote:> There is a bit of slight of hand, > here. A task can not complete > > before it has begun (<grin>). > > That isn't necessarily as clear as you might believe. > If you check an English/Hindi dictionary you will find > that the word for "yesterday" is the same as the word > for "tomorrow" (कल pronounced "kal"). > > This is also deeply embedded (ho ho) in their culture, > which doesn't have an "arrow of time" but does have > a "wheel of time". Well, that makes the problem moot, then! Miss a deadline (window)? Just turn the crank and try again next time 'round!!!
[toc] | [prev] | [next] | [standalone]
| From | Hans-Bernhard Bröker <HBBroeker@t-online.de> |
|---|---|
| Date | 2013-07-27 14:11 +0200 |
| Subject | Re: Does the Buddha have a real time nature? ;) (was Resource revocation) |
| Message-ID | <b5hrn1FarkkU1@mid.dfncis.de> |
| In reply to | #12745 |
On 26.07.2013 23:06, Roberto Waltman wrote: > I am always puzzled by those "definitions" (for lack of a better term) > that seem to ignore the obvious: Real time is about windows/time slots > in which an action is effective. i.e., too early is as bad as too > late. That's because time isn't as symmetric as you make it out to be. We can always delay delivering a result that we already have before it's needed, but there's no way we can deliver a result that we don't have yet. > In a package sorting installation, the diverter that pushes out a box > from a conveyor belt must operate when the box is in front of it, not > after, not before. Which makes the diverter operation synchronized, rather than realtime. The algorithm that figures out whether the diverter ought to be fired, on the other hand, is a realtime task. If that algorithm completes half an hour because that package comes by, that's no more than a minor nuisance. But if it runs a millisecond late, it has failed.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-26 12:40 -0700 |
| Message-ID | <ksujbo$f8c$1@speranza.aioe.org> |
| In reply to | #12728 |
Hi Tom, On 7/26/2013 11:21 AM, Tom Gardner wrote: > On 26/07/13 18:51, Paul Rubin wrote: >> Hans-Bernhard Bröker <HBBroeker@t-online.de> writes: >>> Realtime has nothing to do whatsoever with the length of any >>> particular interval of time. It doesn't matter if your deadline is >>> coming every 50 nanoseconds or once a year. >> >> Pedantically you and Don are correct. > > It isn't pedantic, since that is the only difference > between hard and soft realtime. Exactly. I wrote a 9-track tape "driver" that ran on a 25MHz i386. In "polled" mode, it had to pull a datum off the read head every 6 microseconds. (that's 10-6, not 10-3!) But, it wasn't *hard* real time! If something happened to interrupt me (e.g., NMI), then I would miss a datum (i.e., deadline). But, I could stop the transport, "backup" (which could actually be in the forward direction if I happened to be "reading backwards" at the time) to the previous file mark and then reread the record. Of course, if this happened continuously, I would fail in a big way. (But, NMI's weren't expected to be common!) So, it's a real-time problem because there *is* a dedline; and a SOFT real-time problem because there is value to pursuing the goal after the deadline has passed -- by, essentially, recreating the original problem and making a second attempt at it! :> ) >> In practice in terms of software >> technique, the interval lengths actually matter. > > True, to a large extent. > > But not if, for example, the processor entered a sleep > mode for 364.999 days, woke up and missed the deadline. Exactly. "The spacecraft has LEFT the solar system..." > Engineers are paid to be pessimists; if you don't want > that characteristic, hire a marketeer :) Engineers find the "least bad" solution to problems! (acknowledging that there are rarely any "correct" ones) --don
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-26 21:29 +0100 |
| Message-ID | <%_AIt.8480$kN5.4994@fx05.am4> |
| In reply to | #12738 |
On 26/07/13 20:40, Don Y wrote: > So, it's a real-time problem because there *is* a dedline; and > a SOFT real-time problem because there is value to pursuing the > goal after the deadline has passed -- by, essentially, recreating > the original problem and making a second attempt at it! :> ) As I noted elsewhere, to me the difference between hard and soft realtime is that soft realtime involves stats, e.g. the 95th percentile processing latency will be less that 65ms. But I acknowledge there are other useful definitions of soft realtime :)
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-26 13:52 -0700 |
| Message-ID | <ksunj6$qmd$1@speranza.aioe.org> |
| In reply to | #12742 |
Hi Tom, On 7/26/2013 1:29 PM, Tom Gardner wrote: > On 26/07/13 20:40, Don Y wrote: >> So, it's a real-time problem because there *is* a dedline; and >> a SOFT real-time problem because there is value to pursuing the >> goal after the deadline has passed -- by, essentially, recreating >> the original problem and making a second attempt at it! :> ) > > As I noted elsewhere, to me the difference between hard > and soft realtime is that soft realtime involves stats, > e.g. the 95th percentile processing latency will be less > that 65ms. It's nice if you can quantify your performance. But, I look at it as: the deadline has passed; is there anything I can do to still meet my goal? if not, it's HRT. In the case of the tape transport, the value of obtaining the data from the head diminishes rapidly after the deadline has passed -- especially as that 6us operation turns into a 2sec operation (backspace, reverse, read again). If the transport couldn't backup, then it would have become an HRT problem: once the spacecraft has left the solar system, no use trying for orbital insertion! :> > But I acknowledge there are other useful definitions > of soft realtime :) The important distinction is that it has nothing to do with the "magnitude" or "frequency" of the times involved. "Hard" and "soft" are not synonyms for "Fast" and "slow". (or "often" and "seldom") --don
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-26 22:55 +0100 |
| Message-ID | <pfCIt.19105$FS6.3196@fx10.am4> |
| In reply to | #12744 |
On 26/07/13 21:52, Don Y wrote: > Hi Tom, > > On 7/26/2013 1:29 PM, Tom Gardner wrote: >> On 26/07/13 20:40, Don Y wrote: >>> So, it's a real-time problem because there *is* a dedline; and >>> a SOFT real-time problem because there is value to pursuing the >>> goal after the deadline has passed -- by, essentially, recreating >>> the original problem and making a second attempt at it! :> ) >> >> As I noted elsewhere, to me the difference between hard >> and soft realtime is that soft realtime involves stats, >> e.g. the 95th percentile processing latency will be less >> that 65ms. > > It's nice if you can quantify your performance. But, I look > at it as: the deadline has passed; is there anything I can do to > still meet my goal? if not, it's HRT. That seems very reasonable to me for a large, important, useful class of problems. SRT perf stats of the type I mentioned are common within the telecom industries, where performance, end-user irritation and, (in limiting pernicious cases) correctness are appropriately described by "mostly met" time intervals. More ambiguous would be the case where if your bid arrives after a competing bid, then it is useless. It matches your HRT definition, but the time interval cannot be specified in advance. Such considerations are paramount for the high frequency trading brigade to the extent they are spending the best part of $1bn for their own dedicated trans-Atlantic fibres which will enable them to shave 30ms off message latency! > In the case of the tape transport, the value of obtaining the > data from the head diminishes rapidly after the deadline has > passed -- especially as that 6us operation turns into a 2sec > operation (backspace, reverse, read again). If the transport > couldn't backup, then it would have become an HRT problem: > once the spacecraft has left the solar system, no use trying > for orbital insertion! :> > >> But I acknowledge there are other useful definitions >> of soft realtime :) > > The important distinction is that it has nothing to do with > the "magnitude" or "frequency" of the times involved. > "Hard" and "soft" are not synonyms for "Fast" and "slow". > (or "often" and "seldom") We are in violent agreement there!
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-26 17:22 -0700 |
| Message-ID | <ksv3sg$n7i$1@speranza.aioe.org> |
| In reply to | #12746 |
Hi Tom, On 7/26/2013 2:55 PM, Tom Gardner wrote: >>>> So, it's a real-time problem because there *is* a dedline; and >>>> a SOFT real-time problem because there is value to pursuing the >>>> goal after the deadline has passed -- by, essentially, recreating >>>> the original problem and making a second attempt at it! :> ) >>> >>> As I noted elsewhere, to me the difference between hard >>> and soft realtime is that soft realtime involves stats, >>> e.g. the 95th percentile processing latency will be less >>> that 65ms. >> >> It's nice if you can quantify your performance. But, I look >> at it as: the deadline has passed; is there anything I can do to >> still meet my goal? if not, it's HRT. > > That seems very reasonable to me for a large, important, > useful class of problems. > > SRT perf stats of the type I mentioned are common within > the telecom industries, where performance, end-user > irritation and, (in limiting pernicious cases) correctness > are appropriately described by "mostly met" time intervals. Ah, makes sense. Yes, here telco services (at least LAND lines) are regulated to the level of performance they must provide. (I don't think there are any such guarantees for cellular service?) And, this is evident in people's expectations of that service! I.e., if you pick up a phone (land line) and *don't* get dial tone (I think 2 seconds is the target?) you are really puzzled. OTOH, if you turn on your cell phone and get "no bars", you just grumble and do a pirouette hoping, magically, that the reception will improve somewhere during that spin! :-/ [I once lost service on a landline for a prolonged period of time. It was an unnerving feeling. You *expect* power outages but not *phone* outages!] > More ambiguous would be the case where if your bid arrives > after a competing bid, then it is useless. Assuming the third party *acts* on the earlier bid (?) > It matches your > HRT definition, but the time interval cannot be specified > in advance. Such considerations are paramount for the high > frequency trading brigade to the extent they are spending > the best part of $1bn for their own dedicated trans-Atlantic > fibres which will enable them to shave 30ms off message latency! > >> In the case of the tape transport, the value of obtaining the >> data from the head diminishes rapidly after the deadline has >> passed -- especially as that 6us operation turns into a 2sec >> operation (backspace, reverse, read again). If the transport >> couldn't backup, then it would have become an HRT problem: >> once the spacecraft has left the solar system, no use trying >> for orbital insertion! :> >> >>> But I acknowledge there are other useful definitions >>> of soft realtime :) >> >> The important distinction is that it has nothing to do with >> the "magnitude" or "frequency" of the times involved. >> "Hard" and "soft" are not synonyms for "Fast" and "slow". >> (or "often" and "seldom") > > We are in violent agreement there! I do not understand why these misconceptions persist. Don't folks teach these things anymore? Or, have so many folks resorted to "real fast" examples that the message becomes distorted: people thinking "real fast" is the issue and not "timeliness"? I see this in lots of places. Folklore displacing science. (e.g., don't use dynamic memory allocation; don't use recursion; etc.) Worse yet, the abundance of resources in modern hardware making people oblivious to the costs of those resources (and ways to economize on them) <shrug> --don
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-27 10:02 +0100 |
| Message-ID | <P0MIt.27653$Ma6.4004@fx27.am4> |
| In reply to | #12748 |
On 27/07/13 01:22, Don Y wrote:
> Hi Tom,
>
> On 7/26/2013 2:55 PM, Tom Gardner wrote:
>
>>>>> So, it's a real-time problem because there *is* a dedline; and
>>>>> a SOFT real-time problem because there is value to pursuing the
>>>>> goal after the deadline has passed -- by, essentially, recreating
>>>>> the original problem and making a second attempt at it! :> )
>>>>
>>>> As I noted elsewhere, to me the difference between hard
>>>> and soft realtime is that soft realtime involves stats,
>>>> e.g. the 95th percentile processing latency will be less
>>>> that 65ms.
>>>
>>> It's nice if you can quantify your performance. But, I look
>>> at it as: the deadline has passed; is there anything I can do to
>>> still meet my goal? if not, it's HRT.
>>
>> That seems very reasonable to me for a large, important,
>> useful class of problems.
>>
>> SRT perf stats of the type I mentioned are common within
>> the telecom industries, where performance, end-user
>> irritation and, (in limiting pernicious cases) correctness
>> are appropriately described by "mostly met" time intervals.
>
> Ah, makes sense. Yes, here telco services (at least LAND lines)
> are regulated to the level of performance they must provide.
> (I don't think there are any such guarantees for cellular
> service?) And, this is evident in people's expectations
> of that service!
They may not be regulated, but internally inside networks
the latency is still specified - and measured so that one
subsystem supplier can push responsibility onto another
supplier.
More importantly it is impossible to regulate the vagueries
of the radio propagation channel. People often complain
that multipath reception causes problems, but in mobile
comms it is *required* in order to get reception in
non-line-of-sight positions!
>>> The important distinction is that it has nothing to do with
>>> the "magnitude" or "frequency" of the times involved.
>>> "Hard" and "soft" are not synonyms for "Fast" and "slow".
>>> (or "often" and "seldom")
>>
>> We are in violent agreement there!
>
> I do not understand why these misconceptions persist. Don't
> folks teach these things anymore? Or, have so many folks
> resorted to "real fast" examples that the message becomes
> distorted: people thinking "real fast" is the issue and
> not "timeliness"?
Two reasons:
- "those that can do, those that can't" teach
the next generation
- as employment expands and becomes "old hat", the
brightest minds no longer go into the field and
the top 1% are replaced by the top 10%
If I was starting out again, I'd go into synthetic
biology.
> I see this in lots of places. Folklore displacing science.
> (e.g., don't use dynamic memory allocation; don't use recursion;
> etc.)
The "correct reason" for avoiding malloc and
recursion is to enable the possibility of
correctness proofs. But you know that.
More subtly, interpreted = slow. To thoroughly confuse them,
I point them to HP's Dynamo experience where an
emulated processor running C outperforms the same
non-emulated processor running optimised C (because
the emulation enables the system to optimise the
code that is actually executed, rather than the
code that the compiler is forced to conservatively
guess will be executed.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-27 09:29 -0700 |
| Message-ID | <kt0sgo$rj2$1@speranza.aioe.org> |
| In reply to | #12761 |
Hi Tom, On 7/27/2013 2:02 AM, Tom Gardner wrote: >>> SRT perf stats of the type I mentioned are common within >>> the telecom industries, where performance, end-user >>> irritation and, (in limiting pernicious cases) correctness >>> are appropriately described by "mostly met" time intervals. >> >> Ah, makes sense. Yes, here telco services (at least LAND lines) >> are regulated to the level of performance they must provide. >> (I don't think there are any such guarantees for cellular >> service?) And, this is evident in people's expectations >> of that service! > > They may not be regulated, but internally inside networks > the latency is still specified - and measured so that one > subsystem supplier can push responsibility onto another > supplier. Ah, OK. You are referring to networks in the more modern sense (I was interpreting your comments in the classic telecom sense of "PSTN") > More importantly it is impossible to regulate the vagueries > of the radio propagation channel. People often complain > that multipath reception causes problems, but in mobile > comms it is *required* in order to get reception in > non-line-of-sight positions! Yup. But, here, there is a silent push for telecom providers to move away from "wired land lines" as they are more costly (?) to maintain *and* subject to stricter regulation on QoS than wireless services. E.g., rather than replace existing/damaged land lines, providers would like to provide residences with "immobile cellular stations" that give them access to the wireless network at their "fixed" home-line. >>>> The important distinction is that it has nothing to do with >>>> the "magnitude" or "frequency" of the times involved. >>>> "Hard" and "soft" are not synonyms for "Fast" and "slow". >>>> (or "often" and "seldom") >>> >>> We are in violent agreement there! >> >> I do not understand why these misconceptions persist. Don't >> folks teach these things anymore? Or, have so many folks >> resorted to "real fast" examples that the message becomes >> distorted: people thinking "real fast" is the issue and >> not "timeliness"? > > Two reasons: > - "those that can do, those that can't" teach > the next generation Actually, I was fortunate to have reasonably good instructors. But, I think it was a different era -- where you had to exert more discipline over your "art" than the current reliance on automated tools, "fleshy" languages, bloated libraries, etc. > - as employment expands and becomes "old hat", the > brightest minds no longer go into the field and > the top 1% are replaced by the top 10% Yes. And employers look to find ways to "dumb down" the requirements for the folks they "need" in those positions. Software bloat, hardware overkill, etc. Makes you wonder what will happen when we eventually *do* hit a limit and suddenly have to relearn Ye Olde Ways to make continued advances! :< (hopefully, that'll be past *my* time! :> ) > If I was starting out again, I'd go into synthetic > biology. <frown> I like mechanisms. (I guess you can argue that creating an organic mechanism would be comparable). Hence, I am not usually interested in "desktop software": "Oooooh! Look! I made it blink!" "BFD. Watch me cut a pentagonal hole in this piece of steel...". >> I see this in lots of places. Folklore displacing science. >> (e.g., don't use dynamic memory allocation; don't use recursion; >> etc.) > > The "correct reason" for avoiding malloc and > recursion is to enable the possibility of > correctness proofs. But you know that. Actually, I think more often it is just fear of "common" bugs. (then why not learn how to use these things more effectively?) I happen to be a huge fan of recursion as it makes so many algorithms *so* much easier to implement correctly, out-of-the-box *and* easier to understand (i.e., the equivalent iterative solutions always look like there is a lot of housekeeping going on *in* the code -- lots of opportunities for "little errors"). But, I'm also careful to make sure something in the data implicitly controls the depth of the recursion. For example, I use a recursive "matching" algorithm in one of my TTS systems. But, rather than letting the "input" drive the recursion, I let the *template* do so -- since I can ensure all of the "const" templates have implied limits to the recursion (but I can't make that same guarantee when processing arbitrary "input") The malloc argument I think is just a failure of folks to think about how memory is consumed in their application and, how the heap is administered/implemented in their runtime. E.g., I can often guarantee that malloc handles requests in *constant* time. So, why *not* use it? > More subtly, interpreted = slow. To thoroughly confuse them, > I point them to HP's Dynamo experience where an > emulated processor running C outperforms the same > non-emulated processor running optimised C (because > the emulation enables the system to optimise the > code that is actually executed, rather than the > code that the compiler is forced to conservatively > guess will be executed. Yup. Or, "hand optimized" is better than the compiler's optimizer. Or, vice versa. Too much folklore and not enough hard/empirical data! Yet, people rely on these assumptions to make significant design decisions... :< --don
[toc] | [prev] | [next] | [standalone]
Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web