[oliver: Re: [Caml-list] Real Time Ocaml]

[oliver: Re: [Caml-list] Real Time Ocaml]

[Oliver Bandel]

----- Forwarded message from oliver -----

To: Brian Hurt <bhurt@spnz.org>
Subject: Re: [Caml-list] Real Time Ocaml

On Mon, Apr 19, 2004 at 07:20:38PM -0500, Brian Hurt wrote:
> On Fri, 16 Apr 2004, Basile Starynkevitch wrote:
> 
> > I do not think that re-coding the Ocaml runtime system for hard
> > real-time performance is really realistic (it is doable, but it is a
> > big task, requiring significant expertise), and I suspect that the
> > resulting system would be slower than today's Ocaml, and will perform
> > worse. Real-time garbage collection is tricky and costly (perhaps even
> > needing some kind of read barrier). If you recode the Ocaml GC, you
> > either have to recode the bytecode interpreter or heavily change some
> > tricky parts of the ocamlopt native code generator.
> > 
> 
> First off, having worked in the realtime world, realtime does not mean
> fast.  Quite the contrary, often.  What realtime means is that I can set
> deadlines, that a certain amount of work needs to be done within a given
> time, and can test and prove that the work will, indeed, be done.  Soft
> realtime generally means that missing a deadline, while bad, is not
> catastrophic.  Examples include music and video recording/playback.  
> Missing a deadline means a skip.  Hard realtime means that there are
> catastrophic consequences for missing a deadline- generally, lawyers get
> involved if you miss the deadline.  An example here is the brake
> controller on your car.  Slower isn't the problem, so long as it's a
> constant slower.  It's large differences in time between "common case" and
> "worst case".
[...]

Hard realtime conditions are not "constant delay times".
It is: it's completely deterministic and fitting into the
time constraints!

It can be constant as well as not constant time delay
of an answer. This does not make a distinction here.

A system is a hard-realtime system, when it behaves
completely predictable in respet to delay-time maxima.

And yes, when you write programs on a realtime OS and did not
explicitly forsee limits that fit into your perceptional
harmony, you may wait for a long time to get an answer
(because priority of your task may be very low, if not
 explicitly asking for higher priorities with hard
 realtime conditions beyond millieconds...).




> 
> The only thing non-realtime in Ocaml is the garbage collection.


even purte C-code does not automatically fit into hard-realtime
categories, when the underlying OS does not provide hard realtime
possibilities!

SO the programming language can't help in realtime issues,
if the OS does not provide realtime functionality.
But the language may destroy realtime issues provided by an OS.


Ciao,
   Oliver

P.S.: So called soft realtime is: statistically it is very
      unlikely/uncertain that the realtime condition will
      not be fitted.
      So in soft realtime systems, most of the time the
      time-constraints are matched, and the job is well done,
      but to a certain amoount of cases the realtime conditions
      were failed. So, it's a statistical issue here: nearly
      90% or nearly 99% or nearly 99.99999% of all cases are
      ok, but some rare cases the condition may be not fitted.
      (And undera high system load, the situation may get much
      more worse! Maybe only 50% of the cases fit into the realtime
      conditions... or the system may even break down completely.)

      In hard realtime the time-constraints must be ALWAYS
      fitted/matched, so that 100% of all cases where a realtime
      condition must be fitted into, will and have to be
      fitted!
      So, if you have 0.00000000000000001 % of all cases missing
      the realtime condition, your system is NOT a system that
      can be viewed as a hard-realtime system.
      Hard realtime systems have to fit the time-conditions ALWAYS,
      which means 1 out of 1, 10 out of 10, 10000000000 of 10000000000
      cases and \infty of \infty cases -> ALWAYS and EVER.

      In soft realtime systems, it's sufficient, if the conditions
      were met "often enough", which means to a certin degree of
      likelyhood/certainty.

      1 out of \infty is no problem in mathematics, where you get your
      limes nevertheless. But in hard realtime systems this is
      *absolutely* failure.

      1000 out of 100000 is no problem in soft realtime.


----- End forwarded message -----

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners