Resource revocation - Page 2

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

Translate This Thread From English to

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

Pedantically you and Don are correct.  In practice in terms of software
technique, the interval lengths actually matter.

Re: Resource revocation
On 26/07/13 18:51, Paul Rubin wrote:
Quoted text here. Click to load it

It isn't pedantic, since that is the only difference
between hard and soft realtime.

Quoted text here. Click to load it

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


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

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 ;-).

Re: Resource revocation
On 26/07/13 19:50, Paul Rubin wrote:
Quoted text here. Click to load it

I suspect the IRS imposes just as hard a deadline as the IR does here :)

Quoted text here. Click to load it

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.


Re: Resource revocation
Hi Paul,

On 7/26/2013 11:50 AM, Paul Rubin wrote:
Quoted text here. Click to load it

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



Does the Buddha have a real time nature? ;) (was Resource revocation)
Hans-Bernhard Bröker wrote:
Quoted text here. Click to load it

Don Y wrote:
Quoted text here. Click to load it

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,
We've slightly trimmed the long signature. Click to see the full one.
Re: Does the Buddha have a real time nature? ;) (was Resource revocation)
Hi Roberto,

On 7/26/2013 2:06 PM, Roberto Waltman wrote:
Quoted text here. Click to load it

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.

Quoted text here. Click to load it


Re: Does the Buddha have a real time nature? ;) (was Resource revocation)
On 27/07/13 01:12, Don Y wrote:
Quoted text here. Click to load it

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

Re: Does the Buddha have a real time nature? ;) (was Resource revocation)
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".

Re: Does the Buddha have a real time nature? ;) (was Resource revocation)
Hi Tom,

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

Well, that makes the problem moot, then!  Miss a deadline (window)?
Just turn the crank and try again next time 'round!!!

Re: Does the Buddha have a real time nature? ;) (was Resource revocation)
On 26.07.2013 23:06, Roberto Waltman wrote:

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Re: Resource revocation
Hi Tom,

On 7/26/2013 11:21 AM, Tom Gardner wrote:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

Exactly.  "The spacecraft has LEFT the solar system..."

Quoted text here. Click to load it

Engineers find the "least bad" solution to problems!
(acknowledging that there are rarely any "correct" ones)

--don

Re: Resource revocation
On 26/07/13 20:40, Don Y wrote:
Quoted text here. Click to load 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 :)


Re: Resource revocation
Hi Tom,

On 7/26/2013 1:29 PM, Tom Gardner wrote:
Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

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

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!


Quoted text here. Click to load it

We are in violent agreement there!


Re: Resource revocation
Hi Tom,

On 7/26/2013 2:55 PM, Tom Gardner wrote:

Quoted text here. Click to load it

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

Quoted text here. Click to load it

Assuming the third party *acts* on the earlier bid (?)

Quoted text here. Click to load it

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

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

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!

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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.


Re: Resource revocation
Hi Tom,

On 7/27/2013 2:02 AM, Tom Gardner wrote:

Quoted text here. Click to load it

Ah, OK.  You are referring to networks in the more modern sense
(I was interpreting your comments in the classic telecom sense
of "PSTN")

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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

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

Oh, but "the library [or worse, framework] takes care of all
of that for us". Including solving the byzantine generals'
problem - I think not. :(



Quoted text here. Click to load it

It has been pushed back for a *few* years by the cheap
implementation of multicore processors. But that fails
for more than a few cores due to inescapable memory
bandwidth and latency ans coherence problems.

Long term I think it will have to go down the non-coherent
memory plus message passing route.


Quoted text here. Click to load it

Wow, I made something that'll outlast the human species :) or :(


Quoted text here. Click to load it

Problems arise when the system has been designed and/or
implemented by multiple companies/teams/people. Look at
the problems inherent with using libraries in C++!
(If C++ is the answer, I want to know what the question
was!)


Re: Resource revocation
Hi Tom,

On 7/27/2013 10:20 AM, Tom Gardner wrote:
Quoted text here. Click to load it

And libraries never have bugs?  (how many *digits* in a microsoft
release number??)  :<

I think these "dumbing down" exercises suffer from the problem
of allowing developers to be ignorant of what's inside the box.
Even on a conceptual level!

One reason I enjoy writing in C so much is that I can get a
real feel for what resources are being used, how complex my
algorithm is, etc.  Some of these other "languages" have
too much smoke and mirrors obfuscating what's going on at
the pins of the CPU!

Quoted text here. Click to load it

Yup.  Hence my approach to distributing the automation system
(NoRMA, etc.).  Of course, it's the sort of application (or,
"application set") that lends itself well to decomposition.

[Folklore, malloc, recursion, etc.]

Quoted text here. Click to load it

*** AND POORLY DOCUMENTED! ***

Three of the big (huge!) problems I see with many FOSS projects
are:
- no "ownership" (no one takes responsibility for ensuring
   the quality and consistency of the "product")
- no formal testing (where's the regression suite?  Do you
   expect every developer who touches the codebase to implement
   his/her own test suite?  Replicating the work of others?
   Or, do *none* of them take on this task??  "Leave it to the
   users to find the bugs!")
- no formal documentation (what is the product *supposed* to do?
   Does anyone know?  Or, is it "self-documenting":  it does what
   it does!)

PostgreSQL has been a refreshing defiance of these problems!  :>

Quoted text here. Click to load it

C++ was good for pushing the OOP paradigm into mainstream
thought.  But, it tends to be too heavy-handed in how much
it does for (to?) you -- all the while claiming it is
making your life easier!

OTOH, it has made it much easier for folks examining my
(C) codebase to get used to the structure that I embed in
my data, "objects", etc.  ("Why all these damn structs
all over the place???")

One cute feature I enjoy in Limbo is the use of "tuples".
So, I can make the return of sophisticated types and
pseudo types more obvious:  [silly example]
    (x, y, radius) := describe(a_circle)
is a bit more obvious than:

typedef struct {
   point;
   radius;
} circ_description;

typedef struct {
   coord x;
   coord y;
} point;

...

circ_description result;

...

result = describe(a_circle);

I.e., the original tuple example has implicit in that one
statement the declaration of the types of the returned
parameters -- as well as exposing those parameters to
the reader directly!  (you don't have to chase down the
definitions of the "result")

(there are loads of things that I *don't* like in Limbo
so I revel in the few that I *do* like!  :> )

--don

Site Timeline